Upstream commit 175efa8 is missing from 5.4.y causing "WARNING in iomap_apply" during 5.4.140-rc1 Syzkaller reproducer testing.
175efa8 2020-05-05 Ritesh Harjani ext4: fix EXT4_MAX_LOGICAL_BLOCK macro
------------[ cut here ]------------ WARNING: CPU: 2 PID: 9155 at fs/iomap/apply.c:44 iomap_apply+0x278/0x2b0 fs/iomap/apply.c:44 Kernel panic - not syncing: panic_on_warn set ... CPU: 2 PID: 9155 Comm: syz-executor.7 Not tainted 5.4.140-rc1-syzk #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xd4/0x119 lib/dump_stack.c:118 panic+0x28f/0x6ad kernel/panic.c:221 team0: Port device veth4741 added __warn.cold.12+0x2f/0x2f kernel/panic.c:582 report_bug+0x279/0x300 lib/bug.c:192 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x105/0x170 arch/x86/kernel/traps.c:272 do_invalid_op+0x3b/0x50 arch/x86/kernel/traps.c:291 invalid_op+0x28/0x30 arch/x86/entry/entry_64.S:1029 RIP: 0010:iomap_apply+0x278/0x2b0 fs/iomap/apply.c:44 Code: 81 c4 d8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 3c 85 99 ff 4d 29 e5 4c 89 ad 30 ff ff ff e9 fc fe ff ff e8 28 85 99 ff <0f> 0b 48 c7 c3 fb ff ff ff eb 95 e8 18 85 99 ff 0f 0b 48 c7 c3 fb RSP: 0018:ffff88801dfb7af8 EFLAGS: 00010216 RAX: 0000000000040000 RBX: 0000000000000000 RCX: ffffc90013f11000 RDX: 000000000000218f RSI: ffffffff81dbc858 RDI: 0000000000000006 RBP: ffff88801dfb7bf8 R08: ffff88801ddb5d00 R09: ffffed1002e9249b R10: ffffed1002e9249a R11: ffff8880174924d3 R12: fffffffffffff000 R13: 0000000000000000 R14: ffffffff8e3f76a0 R15: ffff88801dfb7bd0 iomap_bmap+0x13f/0x1a0 fs/iomap/fiemap.c:141 xfs_vm_bmap+0x32b/0x420 fs/xfs/xfs_aops.c:1155 ioctl_fibmap fs/ioctl.c:68 [inline] file_ioctl fs/ioctl.c:502 [inline] do_vfs_ioctl+0xf50/0x1250 fs/ioctl.c:697 ksys_ioctl+0xae/0xd0 fs/ioctl.c:714 __do_sys_ioctl fs/ioctl.c:721 [inline] __se_sys_ioctl fs/ioctl.c:719 [inline] __x64_sys_ioctl+0x78/0xb0 fs/ioctl.c:719 do_syscall_64+0xe6/0x4d0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4595f9 Code: fc ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 0f 83 0b 42 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f8ed3550c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000014a40 RCX: 00000000004595f9 RDX: 00000000200000c0 RSI: 0000000000000001 RDI: 0000000000000004 RBP: 000000000077bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf0c R13: 0000000000021000 R14: 000000000077bf00 R15: 00007f8ed3551700
Ritesh Harjani (1): ext4: fix EXT4_MAX_LOGICAL_BLOCK macro
fs/ext4/ext4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
From: Ritesh Harjani riteshh@linux.ibm.com
ext4 supports max number of logical blocks in a file to be 0xffffffff. (This is since ext4_extent's ee_block is __le32). This means that EXT4_MAX_LOGICAL_BLOCK should be 0xfffffffe (starting from 0 logical offset). This patch fixes this.
The issue was seen when ext4 moved to iomap_fiemap API and when overlayfs was mounted on top of ext4. Since overlayfs was missing filemap_check_ranges(), so it could pass a arbitrary huge length which lead to overflow of map.m_len logic.
This patch fixes that.
Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework") Reported-by: syzbot+77fa5bdb65cc39711820@syzkaller.appspotmail.com Signed-off-by: Ritesh Harjani riteshh@linux.ibm.com Reviewed-by: Jan Kara jack@suse.cz Signed-off-by: Christoph Hellwig hch@lst.de Link: https://lore.kernel.org/r/20200505154324.3226743-2-hch@lst.de Signed-off-by: Theodore Ts'o tytso@mit.edu (cherry picked from commit 175efa81feb8405676e0136d97b10380179c92e0) Signed-off-by: George Kennedy george.kennedy@oracle.com --- fs/ext4/ext4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index bf3eaa9..ae2cb15 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -718,7 +718,7 @@ enum { #define EXT4_MAX_BLOCK_FILE_PHYS 0xFFFFFFFF
/* Max logical block we can support */ -#define EXT4_MAX_LOGICAL_BLOCK 0xFFFFFFFF +#define EXT4_MAX_LOGICAL_BLOCK 0xFFFFFFFE
/* * Structure of an inode on the disk
On Tue, Aug 17, 2021 at 04:12:11PM -0500, George Kennedy wrote:
From: Ritesh Harjani riteshh@linux.ibm.com
ext4 supports max number of logical blocks in a file to be 0xffffffff. (This is since ext4_extent's ee_block is __le32). This means that EXT4_MAX_LOGICAL_BLOCK should be 0xfffffffe (starting from 0 logical offset). This patch fixes this.
The issue was seen when ext4 moved to iomap_fiemap API and when overlayfs was mounted on top of ext4. Since overlayfs was missing filemap_check_ranges(), so it could pass a arbitrary huge length which lead to overflow of map.m_len logic.
This patch fixes that.
Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework") Reported-by: syzbot+77fa5bdb65cc39711820@syzkaller.appspotmail.com Signed-off-by: Ritesh Harjani riteshh@linux.ibm.com Reviewed-by: Jan Kara jack@suse.cz Signed-off-by: Christoph Hellwig hch@lst.de Link: https://lore.kernel.org/r/20200505154324.3226743-2-hch@lst.de Signed-off-by: Theodore Ts'o tytso@mit.edu (cherry picked from commit 175efa81feb8405676e0136d97b10380179c92e0) Signed-off-by: George Kennedy george.kennedy@oracle.com
fs/ext4/ext4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index bf3eaa9..ae2cb15 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -718,7 +718,7 @@ enum { #define EXT4_MAX_BLOCK_FILE_PHYS 0xFFFFFFFF /* Max logical block we can support */ -#define EXT4_MAX_LOGICAL_BLOCK 0xFFFFFFFF +#define EXT4_MAX_LOGICAL_BLOCK 0xFFFFFFFE /*
- Structure of an inode on the disk
-- 1.8.3.1
Now queued up, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org