Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp4192883imb; Wed, 6 Mar 2019 07:32:09 -0800 (PST) X-Google-Smtp-Source: APXvYqzMaB3BuIBTscXXjZzAhnQZppHr/3xAGhYxM7HxoVhcNX3Wb+xzNH3GqLQL0IAsFV4V/q3W X-Received: by 2002:a17:902:282b:: with SMTP id e40mr7563209plb.111.1551886328989; Wed, 06 Mar 2019 07:32:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551886328; cv=none; d=google.com; s=arc-20160816; b=LGxUdu69YbWYP7TiTX6XP8vde1VKCDQ+sc80df5MXaxjdnkYdYBrPJqM3lyqciVGEG amvv2ZVVmaU1WNlgVuEp4SCvhgEsRD6bTj08CuRQIoR+3L72bILpDwR9EDb5N4Xk+2kA +8y6+pI+DaO2ej/XNN22mz/hzJ097b9fTXQixitbGqkLjGjOhcPrQBPk+8l87Qk9LZnZ ac4ydIgqaY2gVmpskcl6G352wQEcJ1IEjX36SlRmUXPhPAbzpjxRFlkVU9mF7BecFmZs c+hT9tsT0G/DmAyizDdmFZRRl2k8N5zzWUF9K5j/fRWxojVcY4Rg/Hh1q/S+2WftAqNg CKFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:to:from; bh=AmOPVun+IAVgs8N7IhRI/yu+hbZYQt4eFwsZwgMrDek=; b=dru37OPApBR5lY67wPY0fmkVNAlm3LBrACne595L5tk8INDkS3Nj99I7gs+JUTKAs8 LAJS0VltJngccNqPZjR7S8CrKiOVkWyK+VUdzdg2MtPzFBKhktcJgKJDjecMfDYENvql lcUBCTY/SoHdlu1wNbDdfAKaMd6GFf3R0cxc6975Nmj1c1LPvuMikGaOnb3r88C4R4am 77AWZEg03+KSy5MSMXlh5nCv9m426srccyA6H1k07yMVW6ZMhix4FReBIL825lOu0t8R OOdtTshawMgi6BeBK81vKmjtEZBZF4rXY1GihhSZPOAOorO8JI3wqEXCVtqBe9/EL58j pqMQ== 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 q5si1599452pgc.425.2019.03.06.07.31.53; Wed, 06 Mar 2019 07:32:08 -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 S1729614AbfCFNAt (ORCPT + 99 others); Wed, 6 Mar 2019 08:00:49 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:5213 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729167AbfCFNAt (ORCPT ); Wed, 6 Mar 2019 08:00:49 -0500 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 92C9EF98DC81A5D0CC9F; Wed, 6 Mar 2019 21:00:46 +0800 (CST) Received: from localhost.localdomain.localdomain (10.175.113.25) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.408.0; Wed, 6 Mar 2019 21:00:37 +0800 From: Hongbo Yao To: , , , Subject: [RFC PATCH 2/2] hrtimer: Prevent overflow for relative refrences Date: Wed, 6 Mar 2019 21:13:26 +0800 Message-ID: <20190306131326.10275-3-yaohongbo@huawei.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190306131326.10275-1-yaohongbo@huawei.com> References: <20190306131326.10275-1-yaohongbo@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.113.25] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I ran Syzkaller testsuite, and got the following call trace. =============================================================== UBSAN: Undefined behaviour in ../kernel/time/hrtimer.c:514:11 signed integer overflow: 9223372036854775807 - -240652746 cannot be represented in type 'long long int' CPU: 1 PID: 9308 Comm: trinity-c5 Not tainted 4.19.25-dirty #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xdd/0x12a ubsan_epilogue+0x10/0x65 handle_overflow+0x1a8/0x212 ? val_to_string.constprop.2+0x137/0x137 ? print_lock_contention_bug+0x190/0x190 ? __next_base+0x2b/0xc0 ? __hrtimer_run_queues+0xca/0x830 __ubsan_handle_sub_overflow+0x11/0x19 __hrtimer_next_event_base+0x1a9/0x1b0 __hrtimer_get_next_event+0x96/0x140 hrtimer_interrupt+0x391/0x610 smp_apic_timer_interrupt+0x137/0x3d0 apic_timer_interrupt+0xf/0x20 =============================================================== Use ktime_sub_safe() which has the necessary sanity checks in place and limits the result to the valid range. Signed-off-by: Hongbo Yao --- kernel/time/hrtimer.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index cadc5bcbfc9e..2195b35af085 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -527,7 +527,8 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base, timer = container_of(next, struct hrtimer, node); } - expires = ktime_sub(hrtimer_get_expires(timer), base->offset); + expires = ktime_sub_safe(hrtimer_get_expires(timer), + base->offset); if (expires < expires_next) { expires_next = expires; @@ -781,7 +782,8 @@ static void hrtimer_reprogram(struct hrtimer *timer, bool reprogram) { struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(&hrtimer_bases); struct hrtimer_clock_base *base = timer->base; - ktime_t expires = ktime_sub(hrtimer_get_expires(timer), base->offset); + ktime_t expires = ktime_sub_safe(hrtimer_get_expires(timer), + base->offset); WARN_ON_ONCE(hrtimer_get_expires_tv64(timer) < 0); -- 2.20.1