[PATCH 5.4.y 0/0] missing upstream commit 175efa8 causing: WARNING in iomap_apply

[PATCH 5.4.y 0/0] missing upstream commit 175efa8 causing: WARNING in iomap_apply

[George Kennedy]

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

[PATCH 5.4.y 0/1] ext4: fix EXT4_MAX_LOGICAL_BLOCK macro

[George Kennedy]

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

Re: [PATCH 5.4.y 0/1] ext4: fix EXT4_MAX_LOGICAL_BLOCK macro

[Greg KH]

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