linux-kernel - Re: [PATCH] mm: Cast the type of unmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1573825937.5937.126.camel@lca.pw>
Date:   Fri, 15 Nov 2019 08:52:17 -0500
From:   Qian Cai <cai@....pw>
To:     Chen Jun <chenjun102@...wei.com>, Hugh Dickins <hughd@...gle.com>,
        linux-mm@...ck.org
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, wangkefeng.wang@...wei.com
Subject: Re: [PATCH] mm: Cast the type of unmap_start to u64

On Fri, 2019-11-15 at 20:24 -0500, Chen Jun wrote:
> 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

What is the syzkaller reproducer if any?

> 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:
> [<ffff800000092150>] dump_backtrace+0x0/0x2c8 arch/arm64/kernel/traps.c:100
> [<ffff800000092438>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:238
> [<ffff800000f9b134>] __dump_stack lib/dump_stack.c:15 [inline]
> [<ffff800000f9b134>] ubsan_epilogue+0x18/0x70 lib/ubsan.c:164
> [<ffff800000f9b468>] handle_overflow+0x158/0x1b0 lib/ubsan.c:195
> [<ffff800000341280>] shmem_fallocate+0x6d0/0x820 mm/shmem.c:2104
> [<ffff8000003ee008>] vfs_fallocate+0x238/0x428 fs/open.c:312
> [<ffff8000003ef72c>] SYSC_fallocate fs/open.c:335 [inline]
> [<ffff8000003ef72c>] 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 <chenjun102@...wei.com>
> ---
>  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;