[syzbot] [ext4?] kernel BUG in ext4_swap_extents

[syzbot] [ext4?] kernel BUG in ext4_swap_extents

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    d1d36025a617 Merge tag 'probes-v6.19' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=138d8992580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=eaa3e2adda258a7
dashboard link: https://syzkaller.appspot.com/bug?extid=4ea6bd8737669b423aae
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=145002c2580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12893c1a580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-d1d36025.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/8198d2c1f670/vmlinux-d1d36025.xz
kernel image: https://storage.googleapis.com/syzbot-assets/51df1359897b/bzImage-d1d36025.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/b2df79151221/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=105002c2580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4ea6bd8737669b423aae@syzkaller.appspotmail.com

------------[ cut here ]------------
kernel BUG at fs/ext4/extents.c:5683!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5528 Comm: syz.0.24 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:ext4_swap_extents+0x196c/0x19a0 fs/ext4/extents.c:5683
Code: fe c1 38 c1 0f 8c 7e fe ff ff e8 1f 17 b3 ff e9 74 fe ff ff e8 b5 79 4b ff 90 0f 0b e8 ad 79 4b ff 90 0f 0b e8 a5 79 4b ff 90 <0f> 0b e8 9d 79 4b ff 90 0f 0b e8 95 79 4b ff 90 0f 0b e8 8d 79 4b
RSP: 0018:ffffc9000cc0f2c0 EFLAGS: 00010293
RAX: ffffffff8275e17b RBX: 0000000000000000 RCX: ffff88801fb324c0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: dffffc0000000000 R08: ffff888042379547 R09: 1ffff1100846f2a8
R10: dffffc0000000000 R11: ffffed100846f2a9 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
FS:  00007fed9d1f96c0(0000) GS:ffff88808d683000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30863fff CR3: 0000000000731000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 mext_move_extent fs/ext4/move_extent.c:396 [inline]
 ext4_move_extents+0x2c58/0x3830 fs/ext4/move_extent.c:616
 __ext4_ioctl fs/ext4/ioctl.c:1652 [inline]
 ext4_ioctl+0x2cf9/0x4760 fs/ext4/ioctl.c:1917
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:597 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fed9c38f7c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fed9d1f9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fed9c5e5fa0 RCX: 00007fed9c38f7c9
RDX: 0000200000000080 RSI: 00000000c028660f RDI: 0000000000000005
RBP: 00007fed9d1f9090 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 00007fed9c5e6038 R14: 00007fed9c5e5fa0 R15: 00007fffbb119b38
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_swap_extents+0x196c/0x19a0 fs/ext4/extents.c:5683
Code: fe c1 38 c1 0f 8c 7e fe ff ff e8 1f 17 b3 ff e9 74 fe ff ff e8 b5 79 4b ff 90 0f 0b e8 ad 79 4b ff 90 0f 0b e8 a5 79 4b ff 90 <0f> 0b e8 9d 79 4b ff 90 0f 0b e8 95 79 4b ff 90 0f 0b e8 8d 79 4b
RSP: 0018:ffffc9000cc0f2c0 EFLAGS: 00010293
RAX: ffffffff8275e17b RBX: 0000000000000000 RCX: ffff88801fb324c0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: dffffc0000000000 R08: ffff888042379547 R09: 1ffff1100846f2a8
R10: dffffc0000000000 R11: ffffed100846f2a9 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
FS:  00007fed9d1f96c0(0000) GS:ffff88808d683000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30863fff CR3: 0000000000731000 CR4: 0000000000352ef0


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Forwarded: [PATCH] ext4: fix missing i_data_sem lock in move_extent repair path

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ext4: fix missing i_data_sem lock in move_extent repair path
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

ext4_swap_extents() requires both i_data_sem locks to be held, as
enforced by BUG_ON checks at the function entry. However, the
repair_branches error path in mext_move_extent() calls
ext4_swap_extents() without holding these locks.

When mext_folio_mkwrite() fails after a successful extent swap, the
code jumps to repair_branches to restore the original extent mapping.
At this point, i_data_sem has already been released, causing the
BUG_ON in ext4_swap_extents() to trigger.

Fix this by acquiring i_data_sem for both inodes before calling
ext4_swap_extents() in the repair_branches path, matching the
locking pattern used in the normal swap path.

Reported-by: syzbot+4ea6bd8737669b423aae@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=4ea6bd8737669b423aae
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/move_extent.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c
index 0550fd30fd10..635fb8a52e0c 100644
--- a/fs/ext4/move_extent.c
+++ b/fs/ext4/move_extent.c
@@ -393,9 +393,11 @@ static int mext_move_extent(struct mext_data *mext, u64 *m_len)
 
 repair_branches:
 	ret2 = 0;
+	ext4_double_down_write_data_sem(orig_inode, donor_inode);
 	r_len = ext4_swap_extents(handle, donor_inode, orig_inode,
 				  mext->donor_lblk, orig_map->m_lblk,
 				  *m_len, 0, &ret2);
+	ext4_double_up_write_data_sem(orig_inode, donor_inode);
 	if (ret2 || r_len != *m_len) {
 		ext4_error_inode_block(orig_inode, (sector_t)(orig_map->m_lblk),
 				       EIO, "Unable to copy data block, data will be lost!");
-- 
2.43.0