From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=DATE_IN_FUTURE_06_12, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35D4DC432C3 for ; Fri, 15 Nov 2019 13:44:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D860920715 for ; Fri, 15 Nov 2019 13:44:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D860920715 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6D8E36B0007; Fri, 15 Nov 2019 08:44:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6620F6B0008; Fri, 15 Nov 2019 08:44:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52A046B000D; Fri, 15 Nov 2019 08:44:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0107.hostedemail.com [216.40.44.107]) by kanga.kvack.org (Postfix) with ESMTP id 365C96B0007 for ; Fri, 15 Nov 2019 08:44:46 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 10330180AD81C for ; Fri, 15 Nov 2019 13:44:46 +0000 (UTC) X-FDA: 76158632172.26.cows69_4642c73b09d13 X-HE-Tag: cows69_4642c73b09d13 X-Filterd-Recvd-Size: 3336 Received: from huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Fri, 15 Nov 2019 13:44:42 +0000 (UTC) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 6A39DA0FE08CF0868D82; Fri, 15 Nov 2019 21:23:46 +0800 (CST) Received: from huawei.com (10.175.104.132) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.439.0; Fri, 15 Nov 2019 21:23:36 +0800 From: Chen Jun To: Hugh Dickins , CC: Andrew Morton , , Subject: [PATCH] mm: Cast the type of unmap_start to u64 Date: Fri, 15 Nov 2019 20:24:24 -0500 Message-ID: <1573867464-5107-1-git-send-email-chenjun102@huawei.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.104.132] X-CFilter-Loop: Reflected X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: In 64bit system. sb->s_maxbytes of shmem filesystem is MAX_LFS_FILESIZE, which equal LLONG_MAX. If offset > LLONG_MAX - PAGE_SIZE, offset + len < LLONG_MAX in shmem_fallocate, which will pass the checking in vfs_fallocate. /* Check for wrap through zero too */ if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0)) return -EFBIG; loff_t unmap_start = round_up(offset, PAGE_SIZE) in shmem_fallocate causes a overflow. Syzkaller reports a overflow problem in mm/shmem: UBSAN: Undefined behaviour in mm/shmem.c:2014:10 signed integer overflow: '9223372036854775807 + 1' cannot be represented in type 'long long int' CPU: 0 PID:17076 Comm: syz-executor0 Not tainted 4.1.46+ #1 Hardware name: linux, dummy-virt (DT) Call trace: [] dump_backtrace+0x0/0x2c8 arch/arm64/kernel/traps.c:100 [] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:238 [] __dump_stack lib/dump_stack.c:15 [inline] [] ubsan_epilogue+0x18/0x70 lib/ubsan.c:164 [] handle_overflow+0x158/0x1b0 lib/ubsan.c:195 [] shmem_fallocate+0x6d0/0x820 mm/shmem.c:2104 [] vfs_fallocate+0x238/0x428 fs/open.c:312 [] SYSC_fallocate fs/open.c:335 [inline] [] SyS_fallocate+0x54/0xc8 fs/open.c:239 The highest bit of unmap_start will be appended with sign bit 1 (overflow) when calculate shmem_falloc.start: shmem_falloc.start = unmap_start >> PAGE_SHIFT. Fix it by casting the type of unmap_start to u64, when right shifted. This bug is found in LTS Linux 4.1. It also seems to exist in mainline. Signed-off-by: Chen Jun --- mm/shmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/shmem.c b/mm/shmem.c index e9342c3..82cebbc 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2717,7 +2717,7 @@ static long shmem_fallocate(struct file *file, int mode, loff_t offset, } shmem_falloc.waitq = &shmem_falloc_waitq; - shmem_falloc.start = unmap_start >> PAGE_SHIFT; + shmem_falloc.start = (u64)unmap_start >> PAGE_SHIFT; shmem_falloc.next = (unmap_end + 1) >> PAGE_SHIFT; spin_lock(&inode->i_lock); inode->i_private = &shmem_falloc; -- 2.7.4