Received: by 10.223.176.5 with SMTP id f5csp3444526wra; Mon, 29 Jan 2018 13:16:32 -0800 (PST) X-Google-Smtp-Source: AH8x225bHjdPrl/89CHHRAtx1XsL6MxQIFpLWy9dKBblXrOdWoYTHJEjN/D+dlb7VqbINP0Z/bn6 X-Received: by 10.101.77.140 with SMTP id p12mr21956694pgq.195.1517260592674; Mon, 29 Jan 2018 13:16:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517260592; cv=none; d=google.com; s=arc-20160816; b=lE7PIejPoQh+EvO9vP30SBi4nyQnjNKATCiZ2nzRt9dq310/BSVvPryyujL1mmK3/q MQ85YlxDZRKjD1g+PNEUwXDkI3m3rOJeYAOsr3n1z/pFtuS8bIAqhZb7QQLPm0yieo1/ YjIQb13k6ZLtkeo7dxG1gaGaRxrJ/2GLHXQ67fS4UAh1r/gUapIanthu7ETRTtdB0lAo f6ETUWe7kgblI8BTnPlnDIBOMMFKc3UJOu8oCPQbyZKHNasR2mys72D5V1JxGoCaZ6+I n4/f50DM6Pic7P0Tj2T1xin83oxFfs5kxhtKv9ckejEEmFCrHrdKHC5SXEqIxjAh65zX uRrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=SmXnQ7O+rW5HHgxBFX0f2vmOAtOtH+dhJ6JMGY84nnk=; b=AHnOTUeeDS7Jvjc4ojzzqyAC8ZVlOuqAPonxSQ4jr9oX7x/IHLUJJdqr46xFjw+vup qWjf9BF/gkJg2fjcj4bQFiuqRF9DcKSdkcoMIkkizdZA8PJlRYrYHiFutli1tP7+r96Y ABlTqv96Z54qJXat6mmjz1QbqFYU7FMbBpq5RVzgNJiIxSrWkdTK5YSPEfMfwElfxHbp vrIAItsQkA+/e8RVvSOcvnMDxFXvkSknheYeZGbN4aMacQsIW3LeFym7aIgrd7pBhad+ WLtf9ovrypWng0PzgLr2xebv1YkvIijNXjzE3L83Pn5tyPeoLMWln6+V0sRaZ1822si+ TtgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a14si7973477pgu.361.2018.01.29.13.16.16; Mon, 29 Jan 2018 13:16:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751423AbeA2VPw (ORCPT + 99 others); Mon, 29 Jan 2018 16:15:52 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:43684 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752358AbeA2UEo (ORCPT ); Mon, 29 Jan 2018 15:04:44 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 7AAFF2EDD; Mon, 29 Jan 2018 13:00:48 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Richard Cochran , Prarit Bhargava , Vegard Nossum , John Stultz , Jiri Slaby Subject: [PATCH 4.4 12/74] time: Avoid undefined behaviour in ktime_add_safe() Date: Mon, 29 Jan 2018 13:56:17 +0100 Message-Id: <20180129123848.101898094@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180129123847.507563674@linuxfoundation.org> References: <20180129123847.507563674@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Vegard Nossum commit 979515c5645830465739254abc1b1648ada41518 upstream. I ran into this: ================================================================================ UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16 signed integer overflow: 9223372036854775807 + 50000 cannot be represented in type 'long long int' CPU: 2 PID: 4798 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #91 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 0000000000000000 ffff88010ce6fb88 ffffffff82344740 0000000041b58ab3 ffffffff84f97a20 ffffffff82344694 ffff88010ce6fbb0 ffff88010ce6fb60 000000000000c350 ffff88010ce6f968 dffffc0000000000 ffffffff857bc320 Call Trace: [] dump_stack+0xac/0xfc [] ? _atomic_dec_and_lock+0xc4/0xc4 [] ubsan_epilogue+0xd/0x8a [] handle_overflow+0x202/0x23d [] ? val_to_string.constprop.6+0x11e/0x11e [] ? timerqueue_add+0x151/0x410 [] ? hrtimer_start_range_ns+0x3b8/0x1380 [] ? memset+0x31/0x40 [] __ubsan_handle_add_overflow+0xe/0x10 [] hrtimer_nanosleep+0x5d9/0x790 [] ? hrtimer_init_sleeper+0x80/0x80 [] ? __might_sleep+0x5b/0x260 [] common_nsleep+0x20/0x30 [] SyS_clock_nanosleep+0x197/0x210 [] ? SyS_clock_getres+0x150/0x150 [] ? __this_cpu_preempt_check+0x13/0x20 [] ? __context_tracking_exit.part.3+0x30/0x1b0 [] ? SyS_clock_getres+0x150/0x150 [] do_syscall_64+0x1b3/0x4b0 [] entry_SYSCALL64_slow_path+0x25/0x25 ================================================================================ Add a new ktime_add_unsafe() helper which doesn't check for overflow, but doesn't throw a UBSAN warning when it does overflow either. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Signed-off-by: Vegard Nossum Signed-off-by: John Stultz Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman --- include/linux/ktime.h | 7 +++++++ kernel/time/hrtimer.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) --- a/include/linux/ktime.h +++ b/include/linux/ktime.h @@ -64,6 +64,13 @@ static inline ktime_t ktime_set(const s6 ({ (ktime_t){ .tv64 = (lhs).tv64 + (rhs).tv64 }; }) /* + * Same as ktime_add(), but avoids undefined behaviour on overflow; however, + * this means that you must check the result for overflow yourself. + */ +#define ktime_add_unsafe(lhs, rhs) \ + ({ (ktime_t){ .tv64 = (u64) (lhs).tv64 + (rhs).tv64 }; }) + +/* * Add a ktime_t variable and a scalar nanosecond value. * res = kt + nsval: */ --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -312,7 +312,7 @@ EXPORT_SYMBOL_GPL(__ktime_divns); */ ktime_t ktime_add_safe(const ktime_t lhs, const ktime_t rhs) { - ktime_t res = ktime_add(lhs, rhs); + ktime_t res = ktime_add_unsafe(lhs, rhs); /* * We use KTIME_SEC_MAX here, the maximum timeout which we can