Skip to contentSkip to conversation

mm: Cast the type of unmap_start to u64

PATCH In review Chen Jun 2 participants 2 messages Nov 15, 2019

Subsystems (2)
lore
Share & tools
lore

Chen Jun

author
#0 lore raw

PATCH 1/1 mm: Cast the type of unmap_start to u64

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:
[<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.

---
 mm/shmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/shmem.c +1 -1
index e9342c3..82cebbc 100644
@@ -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;
Signature · 1 line
2.7.4
#1 lore raw
Quoted 8 lines · Chen Jun

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;
Quoted 5 lines

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?

Quoted 41 lines

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.

---
 mm/shmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/shmem.c +1 -1
index e9342c3..82cebbc 100644
@@ -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;