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(-)
--
1.8.3.1
From: Ritesh Harjani <[email protected]>
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: [email protected]
Signed-off-by: Ritesh Harjani <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
(cherry picked from commit 175efa81feb8405676e0136d97b10380179c92e0)
Signed-off-by: George Kennedy <[email protected]>
---
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
On Tue, Aug 17, 2021 at 04:12:11PM -0500, George Kennedy wrote:
> From: Ritesh Harjani <[email protected]>
>
> 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: [email protected]
> Signed-off-by: Ritesh Harjani <[email protected]>
> Reviewed-by: Jan Kara <[email protected]>
> Signed-off-by: Christoph Hellwig <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Theodore Ts'o <[email protected]>
> (cherry picked from commit 175efa81feb8405676e0136d97b10380179c92e0)
> Signed-off-by: George Kennedy <[email protected]>
> ---
> 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