Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1589250pxk; Tue, 1 Sep 2020 02:35:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdaPKz9T42pCbVoB+cMcXE7BlpCS9QCbOeifrafM7jCgcKQBndfwRGEHpYHMSwprN+JdXV X-Received: by 2002:a17:906:af53:: with SMTP id ly19mr91826ejb.503.1598952903837; Tue, 01 Sep 2020 02:35:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598952903; cv=none; d=google.com; s=arc-20160816; b=nzTdzxK2rJIu5JlocE0ZFyVLkptjyX+KxR/0ODcZtBtcxR+Sx4akj90L3DySoUErAY s8iE8WFNXx7VcDFyXMTNfcL+fDMBp/mz5l5n49TNU+99XdzWQ/aRXkSIiIsRb1xlDXgr wLvwJo4+rOwBaHRoNCQrRA8lo1ML5jPWUQIx8i0RfSlvtak7IpFv0CyEcwyZ0qUtLftH 7HXkNXkF2AVYND3V3ce+E3l5DpUnk/Daa0Rb2wH6W7Z1xc93filt8puP0N+Vzx5N3auC wtzfZk3xL1uDSbwn1v9dT+v2Unoc4wBd9eIOLaQc8j5xnT+z77hRxjICnHTzfLbjSYlc 84Sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=elDeuTuihT75syf+4tXepE0J4BW3vwoqDv4tVa/6Bu4=; b=p2gAXPf6h+/lpqZhRCZUubZeug+WR6Ic3S2S08PaUAl60QxctgSQlnW219xyeIE+FC 9qdvWMKfySPKf4h3NMt3I/x5qAVuYOpcyEb0+AX/VTb250LUTebcMoZeuBljTZcPXkdB FHjb9PEAVGV2Mi5W4JGbOZQ0Zgy+sW6X9diHNXq5Z52ccmXdMElzpckwkXO+YDdfxpan zQa8lZChMmpEPuxXHIISHC+AaWa6Dj3WukQKCpbFrHyKcoukVoiOQ6n8Un1ocBVaASjp 5X/hipob3sTvu/HFlp4qFN8j79rdq9i7H+Dof6YPouVwi+5V+tyPAj8CQJQVvqPsQ3Kl ET3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n20si338064ejo.160.2020.09.01.02.34.40; Tue, 01 Sep 2020 02:35:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726446AbgIAJbp (ORCPT + 99 others); Tue, 1 Sep 2020 05:31:45 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:45690 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726192AbgIAJbn (ORCPT ); Tue, 1 Sep 2020 05:31:43 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 6AF11EA56FCAAD2861CD; Tue, 1 Sep 2020 17:31:41 +0800 (CST) Received: from localhost.localdomain (10.67.165.24) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.487.0; Tue, 1 Sep 2020 17:31:30 +0800 From: Zeng Tao To: CC: , Zeng Tao , Vincenzo Frascino , Subject: [PATCH] time: Avoid undefined behaviour in timespec64_to_ns Date: Tue, 1 Sep 2020 17:30:13 +0800 Message-ID: <1598952616-6416-1-git-send-email-prime.zeng@hisilicon.com> X-Mailer: git-send-email 2.8.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.165.24] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I got into this: ================================================================================ UBSAN: Undefined behaviour in ./include/linux/time64.h:127:27 signed integer overflow: 17179869187 * 1000000000 cannot be represented in type 'long long int' CPU: 0 PID: 4265 Comm: syz-executor.0 Not tainted 5.6.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xc6/0x11e lib/dump_stack.c:118 ubsan_epilogue+0xa/0x30 lib/ubsan.c:154 handle_overflow+0x119/0x130 lib/ubsan.c:184 timespec64_to_ns include/linux/time64.h:127 [inline] set_cpu_itimer+0x65c/0x880 kernel/time/itimer.c:180 do_setitimer+0x8e/0x740 kernel/time/itimer.c:245 __do_sys_setitimer kernel/time/itimer.c:353 [inline] __se_sys_setitimer kernel/time/itimer.c:336 [inline] __x64_sys_setitimer+0x14c/0x2c0 kernel/time/itimer.c:336 do_syscall_64+0xa1/0x540 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x4674d9 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f63de999c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000026 RAX: ffffffffffffffda RBX: 000000000074bf00 RCX: 00000000004674d9 RDX: 0000000020000080 RSI: 0000000020000040 RDI: 0000000000000001 RBP: 00007f63de99a6bc R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 0000000000000a1c R14: 00000000004cb300 R15: 0000000000701660 ================================================================================ when i ran the syzkaller. Since commit bd40a175769d ("y2038: itimer: change implementation to timespec64") we have break the time clamping which handles the potential overflow. In this patch, we fix it in the timespec64_to_ns because there is possiblity to cause the same undefined behaviour on overflow whenever the function is called. Fixes: bd40a175769d ("y2038: itimer: change implementation to timespec64") Signed-off-by: Zeng Tao --- include/linux/time64.h | 3 +++ kernel/time/itimer.c | 4 ---- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/include/linux/time64.h b/include/linux/time64.h index c9dcb3e..3215593 100644 --- a/include/linux/time64.h +++ b/include/linux/time64.h @@ -124,6 +124,9 @@ static inline bool timespec64_valid_settod(const struct timespec64 *ts) */ static inline s64 timespec64_to_ns(const struct timespec64 *ts) { + if ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX) + return KTIME_MAX; + return ((s64) ts->tv_sec * NSEC_PER_SEC) + ts->tv_nsec; } diff --git a/kernel/time/itimer.c b/kernel/time/itimer.c index ca4e6d5..00629e6 100644 --- a/kernel/time/itimer.c +++ b/kernel/time/itimer.c @@ -172,10 +172,6 @@ static void set_cpu_itimer(struct task_struct *tsk, unsigned int clock_id, u64 oval, nval, ointerval, ninterval; struct cpu_itimer *it = &tsk->signal->it[clock_id]; - /* - * Use the to_ktime conversion because that clamps the maximum - * value to KTIME_MAX and avoid multiplication overflows. - */ nval = timespec64_to_ns(&value->it_value); ninterval = timespec64_to_ns(&value->it_interval); -- 2.8.1