[syzbot] [ext4?] INFO: task hung in filename_unlinkat

[syzbot] [ext4?] INFO: task hung in filename_unlinkat

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    a95f71ad3e2e Merge tag 'for-linus' of git://git.kernel.org..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15cfc55a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=abe4fa590468dbfb
dashboard link: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11294eaa580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14a47c02580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/8676ab01a8b8/disk-a95f71ad.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/e3314e350353/vmlinux-a95f71ad.xz
kernel image: https://storage.googleapis.com/syzbot-assets/6e2905ccbd1e/bzImage-a95f71ad.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/94e3ac0ab12f/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=14a88152580000)

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

INFO: task syz.0.17:5995 blocked for more than 143 seconds.
      Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.0.17        state:D stack:29024 pid:5995  tgid:5990  ppid:5927   task_flags:0x400040 flags:0x00080002
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5295 [inline]
 __schedule+0x14fb/0x52c0 kernel/sched/core.c:6907
 __schedule_loop kernel/sched/core.c:6989 [inline]
 rt_mutex_schedule+0x76/0xf0 kernel/sched/core.c:7285
 rt_mutex_slowlock_block kernel/locking/rtmutex.c:1647 [inline]
 __rt_mutex_slowlock kernel/locking/rtmutex.c:1721 [inline]
 __rt_mutex_slowlock_locked+0x1f8f/0x25c0 kernel/locking/rtmutex.c:1760
 rt_mutex_slowlock+0xbd/0x170 kernel/locking/rtmutex.c:1800
 __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline]
 rwbase_write_lock+0x14d/0x730 kernel/locking/rwbase_rt.c:244
 inode_lock_nested include/linux/fs.h:1073 [inline]
 __start_dirop fs/namei.c:2923 [inline]
 start_dirop fs/namei.c:2934 [inline]
 filename_unlinkat+0x2ad/0x610 fs/namei.c:5521
 __do_sys_unlink fs/namei.c:5575 [inline]
 __se_sys_unlink+0x2e/0x140 fs/namei.c:5572
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f6cd2b5c629
RSP: 002b:00007f6cd2195028 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
RAX: ffffffffffffffda RBX: 00007f6cd2dd6090 RCX: 00007f6cd2b5c629
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000180
RBP: 00007f6cd2bf2b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f6cd2dd6128 R14: 00007f6cd2dd6090 R15: 00007ffd3df50108
 </TASK>

Showing all locks held in the system:
4 locks held by pr/legacy/17:
1 lock held by khungtaskd/38:
 #0: ffffffff8ddcd780 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
 #0: ffffffff8ddcd780 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
 #0: ffffffff8ddcd780 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x2e/0x180 kernel/locking/lockdep.c:6775
4 locks held by kworker/u8:6/783:
3 locks held by kworker/u8:11/1173:
2 locks held by getty/5552:
 #0: ffff888036cdf0a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
 #1: ffffc90003e832e0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x462/0x13c0 drivers/tty/n_tty.c:2211
7 locks held by syz.0.17/5991:
2 locks held by syz.0.17/5995:
 #0: ffff888034904480 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:493
 #1: ffff888054ce9c70 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:1073 [inline]
 #1: ffff888054ce9c70 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: __start_dirop fs/namei.c:2923 [inline]
 #1: ffff888054ce9c70 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: start_dirop fs/namei.c:2934 [inline]
 #1: ffff888054ce9c70 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: filename_unlinkat+0x2ad/0x610 fs/namei.c:5521
7 locks held by syz.1.18/6018:
2 locks held by syz.1.18/6022:
 #0: ffff8880294e6480 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:493
 #1: ffff888044ea3430 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:1073 [inline]
 #1: ffff888044ea3430 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: __start_dirop fs/namei.c:2923 [inline]
 #1: ffff888044ea3430 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: start_dirop fs/namei.c:2934 [inline]
 #1: ffff888044ea3430 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: filename_unlinkat+0x2ad/0x610 fs/namei.c:5521
6 locks held by syz.2.19/6044:
2 locks held by syz.2.19/6048:
 #0: ffff8880247b0480 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:493
 #1: ffff888044c92850 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:1073 [inline]
 #1: ffff888044c92850 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: __start_dirop fs/namei.c:2923 [inline]
 #1: ffff888044c92850 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: start_dirop fs/namei.c:2934 [inline]
 #1: ffff888044c92850 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: filename_unlinkat+0x2ad/0x610 fs/namei.c:5521
3 locks held by syz.3.20/6075:
2 locks held by syz.3.20/6080:
 #0: ffff888034d36480 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:493
 #1: ffff888054cee3b0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:1073 [inline]
 #1: ffff888054cee3b0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: __start_dirop fs/namei.c:2923 [inline]
 #1: ffff888054cee3b0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: start_dirop fs/namei.c:2934 [inline]
 #1: ffff888054cee3b0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: filename_unlinkat+0x2ad/0x610 fs/namei.c:5521
7 locks held by syz.4.21/6113:
2 locks held by syz.4.21/6117:
 #0: ffff888035624480 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:493
 #1: ffff888044c9cbf0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:1073 [inline]
 #1: ffff888044c9cbf0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: __start_dirop fs/namei.c:2923 [inline]
 #1: ffff888044c9cbf0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: start_dirop fs/namei.c:2934 [inline]
 #1: ffff888044c9cbf0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: filename_unlinkat+0x2ad/0x610 fs/namei.c:5521
7 locks held by syz.5.22/6147:
2 locks held by syz.5.22/6151:
 #0: ffff88804c26c480 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:493
 #1: ffff888044c96f90 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:1073 [inline]
 #1: ffff888044c96f90 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: __start_dirop fs/namei.c:2923 [inline]
 #1: ffff888044c96f90 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: start_dirop fs/namei.c:2934 [inline]
 #1: ffff888044c96f90 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: filename_unlinkat+0x2ad/0x610 fs/namei.c:5521
7 locks held by syz.6.23/6185:
2 locks held by syz.6.23/6190:
 #0: ffff888025968480 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x41/0x90 fs/namespace.c:493
 #1: ffff888044e5c010 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: inode_lock_nested include/linux/fs.h:1073 [inline]
 #1: ffff888044e5c010 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: __start_dirop fs/namei.c:2923 [inline]
 #1: ffff888044e5c010 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: start_dirop fs/namei.c:2934 [inline]
 #1: ffff888044e5c010 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: filename_unlinkat+0x2ad/0x610 fs/namei.c:5521
3 locks held by udevd/6219:
5 locks held by syz.7.24/6221:

=============================================

NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 38 Comm: khungtaskd Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 nmi_cpu_backtrace+0x274/0x2d0 lib/nmi_backtrace.c:113
 nmi_trigger_cpumask_backtrace+0x17a/0x300 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:161 [inline]
 __sys_info lib/sys_info.c:157 [inline]
 sys_info+0x135/0x170 lib/sys_info.c:165
 check_hung_uninterruptible_tasks kernel/hung_task.c:346 [inline]
 watchdog+0xfd9/0x1030 kernel/hung_task.c:515
 kthread+0x388/0x470 kernel/kthread.c:467
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 783 Comm: kworker/u8:6 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Workqueue: bat_events batadv_dat_purge
RIP: 0010:__local_bh_enable_ip+0x1c2/0x2b0 kernel/softirq.c:307
Code: f7 89 df e8 60 01 00 00 41 f7 c4 00 02 00 00 74 05 e8 52 60 44 00 9c 58 a9 00 02 00 00 75 23 41 f7 c4 00 02 00 00 74 01 fb 5b <41> 5c 41 5d 41 5e 41 5f 5d e9 c0 d7 9d 09 cc 90 0f 0b 90 e9 66 fe
RSP: 0018:ffffc900046ffa58 EFLAGS: 00000206
RAX: 0000000000000006 RBX: ffffffffffffffe8 RCX: 0000000000000046
RDX: 0000000000000006 RSI: ffffffff8d55b178 RDI: ffffffff8ba64380
RBP: 1ffff11004a23cc4 R08: ffffffff8f6a23b7 R09: 1ffffffff1ed4476
R10: dffffc0000000000 R11: fffffbfff1ed4477 R12: 0000000000000286
R13: dffffc0000000000 R14: ffff88802511e624 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffff888126442000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2fb63fff CR3: 00000000354ae000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 spin_unlock_bh include/linux/spinlock_rt.h:116 [inline]
 __batadv_dat_purge+0x344/0x400 net/batman-adv/distributed-arp-table.c:185
 batadv_dat_purge+0x20/0x70 net/batman-adv/distributed-arp-table.c:204
 process_one_work kernel/workqueue.c:3275 [inline]
 process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
 worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
 kthread+0x388/0x470 kernel/kthread.c:467
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>


---
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

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[Edward Adam Davis]

#syz test

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 293f698b7042..4b72da4d646f 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2425,6 +2425,8 @@ struct ext4_dir_entry_2 {
 	char	name[EXT4_NAME_LEN];	/* File name */
 };
 
+#define DIFF_AREA_DE_XH sizeof(struct ext4_dir_entry_2)
+
 /*
  * Access the hashes at the end of ext4_dir_entry_2
  */
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..313c460a93c5 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -2160,7 +2160,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
 				error = -EIO;
 				goto getblk_failed;
 			}
-			memcpy(new_bh->b_data, s->base, new_bh->b_size);
+			memcpy(new_bh->b_data + DIFF_AREA_DE_XH, s->base, new_bh->b_size);
 			ext4_xattr_block_csum_set(inode, new_bh);
 			set_buffer_uptodate(new_bh);
 			unlock_buffer(new_bh);
diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h
index 1fedf44d4fb6..4a28023c72e8 100644
--- a/fs/ext4/xattr.h
+++ b/fs/ext4/xattr.h
@@ -8,6 +8,7 @@
 */
 
 #include <linux/xattr.h>
+#include "ext4.h"
 
 /* Magic value in attribute blocks */
 #define EXT4_XATTR_MAGIC		0xEA020000
@@ -90,7 +91,7 @@ struct ext4_xattr_entry {
 #define EXT4_XATTR_MIN_LARGE_EA_SIZE(b)					\
 	((b) - EXT4_XATTR_LEN(3) - sizeof(struct ext4_xattr_header) - 4)
 
-#define BHDR(bh) ((struct ext4_xattr_header *)((bh)->b_data))
+#define BHDR(bh) ((struct ext4_xattr_header *)((bh)->b_data + DIFF_AREA_DE_XH))
 #define ENTRY(ptr) ((struct ext4_xattr_entry *)(ptr))
 #define BFIRST(bh) ENTRY(BHDR(bh)+1)
 #define IS_LAST_ENTRY(entry) (*(__u32 *)(entry) == 0)

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com

Tested on:

commit:         eb71ab2b Merge tag 'bpf-fixes' of git://git.kernel.org..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16a7d55a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=70fe0401f305d8d4
dashboard link: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=15c768d6580000

Note: testing is done by a robot and is best-effort only.

[PATCH] ext4: avoid infinite loops caused by data conflicts

[Edward Adam Davis]

In the execution paths of mkdir and openat, there are two different
structures, struct ext4_xattr_header and struct ext4_dir_entry_2,
that both reference the same buffer head.

In the mkdir path, ext4_add_entry() first sets the rec_len member of
the struct ext4_dir_entry_2 to 2048, and then sets the file_type value
to 2 in add_dirent_to_buf()->ext4_insert_dentry()->ext4_set_de_type().

This causes the h_refcount value in the other struct ext4_xattr_header,
which references the same buffer head, to be too large in the openat
path.

The above causes ext4_xattr_block_set() to enter an infinite loop about
"inserted" and cannot release the inode lock, ultimately leading to the
143s blocking problem mentioned in [1].

When accessing the ext4_xattr_header structure in xattr, the accessed
buffer head data is placed after ext4_dir_entry_2 to prevent data
collisions caused by data overlap.

[1]
INFO: task syz.0.17:5995 blocked for more than 143 seconds.
Call Trace:
 inode_lock_nested include/linux/fs.h:1073 [inline]
 __start_dirop fs/namei.c:2923 [inline]
 start_dirop fs/namei.c:2934 [inline]

Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/ext4/ext4.h  | 2 ++
 fs/ext4/xattr.c | 2 +-
 fs/ext4/xattr.h | 3 ++-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 293f698b7042..4b72da4d646f 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2425,6 +2425,8 @@ struct ext4_dir_entry_2 {
 	char	name[EXT4_NAME_LEN];	/* File name */
 };
 
+#define DIFF_AREA_DE_XH sizeof(struct ext4_dir_entry_2)
+
 /*
  * Access the hashes at the end of ext4_dir_entry_2
  */
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..313c460a93c5 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -2160,7 +2160,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
 				error = -EIO;
 				goto getblk_failed;
 			}
-			memcpy(new_bh->b_data, s->base, new_bh->b_size);
+			memcpy(new_bh->b_data + DIFF_AREA_DE_XH, s->base, new_bh->b_size);
 			ext4_xattr_block_csum_set(inode, new_bh);
 			set_buffer_uptodate(new_bh);
 			unlock_buffer(new_bh);
diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h
index 1fedf44d4fb6..4a28023c72e8 100644
--- a/fs/ext4/xattr.h
+++ b/fs/ext4/xattr.h
@@ -8,6 +8,7 @@
 */
 
 #include <linux/xattr.h>
+#include "ext4.h"
 
 /* Magic value in attribute blocks */
 #define EXT4_XATTR_MAGIC		0xEA020000
@@ -90,7 +91,7 @@ struct ext4_xattr_entry {
 #define EXT4_XATTR_MIN_LARGE_EA_SIZE(b)					\
 	((b) - EXT4_XATTR_LEN(3) - sizeof(struct ext4_xattr_header) - 4)
 
-#define BHDR(bh) ((struct ext4_xattr_header *)((bh)->b_data))
+#define BHDR(bh) ((struct ext4_xattr_header *)((bh)->b_data + DIFF_AREA_DE_XH))
 #define ENTRY(ptr) ((struct ext4_xattr_entry *)(ptr))
 #define BFIRST(bh) ENTRY(BHDR(bh)+1)
 #define IS_LAST_ENTRY(entry) (*(__u32 *)(entry) == 0)
-- 
2.43.0

[syzbot ci] Re: ext4: avoid infinite loops caused by data conflicts

[syzbot ci]

syzbot ci has tested the following series

[v1] ext4: avoid infinite loops caused by data conflicts
https://lore.kernel.org/all/tencent_4C5966F83C65375A97D236684A6C75237609@qq.com
* [PATCH] ext4: avoid infinite loops caused by data conflicts

and found the following issues:
* KASAN: slab-out-of-bounds Write in ext4_xattr_block_set
* KASAN: slab-use-after-free Read in do_exit
* KASAN: slab-use-after-free Write in ext4_xattr_block_set
* KASAN: use-after-free Write in ext4_xattr_block_set
* WARNING in ext4_xattr_block_set

Full report is available here:
https://ci.syzbot.org/series/175d31ab-3a77-4fe8-ba80-457d1e9b7ff0

***

KASAN: slab-out-of-bounds Write in ext4_xattr_block_set

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      eb71ab2bf72260054677e348498ba995a057c463
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/fba2a0c2-e161-4ef9-a2c8-ddca4c80da09/config
C repro:   https://ci.syzbot.org/findings/7226f006-36f9-4dc2-8e42-67ddd1662a4a/c_repro
syz repro: https://ci.syzbot.org/findings/7226f006-36f9-4dc2-8e42-67ddd1662a4a/syz_repro

loop0: lost filesystem error report for type 5 error -117
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
==================================================================
BUG: KASAN: slab-out-of-bounds in ext4_xattr_block_set+0x247e/0x2b00 fs/ext4/xattr.c:2163
Write of size 1024 at addr ffff88810eafad08 by task syz.0.17/5950

CPU: 1 UID: 0 PID: 5950 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 check_region_inline mm/kasan/generic.c:-1 [inline]
 kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200
 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
 ext4_xattr_block_set+0x247e/0x2b00 fs/ext4/xattr.c:2163
 ext4_xattr_move_to_block fs/ext4/xattr.c:2669 [inline]
 ext4_xattr_make_inode_space fs/ext4/xattr.c:2744 [inline]
 ext4_expand_extra_isize_ea+0x12e6/0x1eb0 fs/ext4/xattr.c:2832
 __ext4_expand_extra_isize+0x30d/0x400 fs/ext4/inode.c:6297
 ext4_try_to_expand_extra_isize fs/ext4/inode.c:6340 [inline]
 __ext4_mark_inode_dirty+0x45c/0x730 fs/ext4/inode.c:6418
 ext4_setattr+0x166e/0x1c60 fs/ext4/inode.c:5932
 notify_change+0xc1a/0xf40 fs/attr.c:556
 do_truncate+0x1c2/0x250 fs/open.c:68
 vfs_truncate+0x4b4/0x540 fs/open.c:118
 do_sys_truncate+0xf3/0x1c0 fs/open.c:142
 __do_sys_truncate fs/open.c:154 [inline]
 __se_sys_truncate fs/open.c:152 [inline]
 __x64_sys_truncate+0x5b/0x70 fs/open.c:152
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f608c79c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f608bdfe028 EFLAGS: 00000246 ORIG_RAX: 000000000000004c
RAX: ffffffffffffffda RBX: 00007f608ca15fa0 RCX: 00007f608c79c799
RDX: 0000000000000000 RSI: 0000000003000000 RDI: 0000200000000900
RBP: 00007f608c832bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f608ca16038 R14: 00007f608ca15fa0 R15: 00007ffe3b059518
 </TASK>

The buggy address belongs to the physical page:
page: refcount:2 mapcount:0 mapping:ffff88810783d900 index:0x8 pfn:0x10eafa
memcg:ffff8881026b9b00
aops:def_blk_aops ino:700000 dentry name(?):""
flags: 0x17ff38000004a2c(referenced|uptodate|lru|workingset|owner_2|private|node=0|zone=2|lastcpupid=0x7ff)
raw: 017ff38000004a2c ffffea00044efa08 ffffea00043dc788 ffff88810783d900
raw: 0000000000000008 ffff8881bb9b4740 00000002ffffffff ffff8881026b9b00
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x152c40(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_HARDWALL), pid 5814, tgid 5814 (udevd), ts 64590193146, free_ts 64427187441
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2484
 alloc_frozen_pages_noprof mm/mempolicy.c:2555 [inline]
 alloc_pages_noprof+0xa8/0x190 mm/mempolicy.c:2575
 folio_alloc_noprof+0x1e/0x30 mm/mempolicy.c:2585
 filemap_alloc_folio_noprof+0x111/0x470 mm/filemap.c:1013
 ractl_alloc_folio mm/readahead.c:189 [inline]
 page_cache_ra_unbounded+0x39b/0xa50 mm/readahead.c:277
 do_page_cache_ra mm/readahead.c:334 [inline]
 force_page_cache_ra+0x26e/0x2e0 mm/readahead.c:364
 filemap_get_pages+0x4c0/0x1f10 mm/filemap.c:2690
 filemap_read+0x447/0x1230 mm/filemap.c:2800
 blkdev_read_iter+0x30a/0x440 block/fops.c:855
 new_sync_read fs/read_write.c:493 [inline]
 vfs_read+0x582/0xa70 fs/read_write.c:574
 ksys_read+0x150/0x270 fs/read_write.c:717
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 12 tgid 12 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 __free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
 vfree+0x25a/0x400 mm/vmalloc.c:3479
 __ebt_unregister_table+0x3d3/0x600 net/bridge/netfilter/ebtables.c:1174
 ops_exit_list net/core/net_namespace.c:199 [inline]
 ops_undo_list+0x49f/0x940 net/core/net_namespace.c:252
 cleanup_net+0x56b/0x800 net/core/net_namespace.c:704
 process_one_work kernel/workqueue.c:3275 [inline]
 process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
 worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
 kthread+0x388/0x470 kernel/kthread.c:467
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
 ffff88810eafaf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88810eafb000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88810eafb080: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc 00 00
                                     ^
 ffff88810eafb100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88810eafb180: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00
==================================================================


***

KASAN: slab-use-after-free Read in do_exit

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      eb71ab2bf72260054677e348498ba995a057c463
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/fba2a0c2-e161-4ef9-a2c8-ddca4c80da09/config
syz repro: https://ci.syzbot.org/findings/30fcf15f-7140-40ad-abff-af01ef67fdf0/syz_repro

==================================================================
BUG: KASAN: slab-use-after-free in stack_not_used kernel/exit.c:800 [inline]
BUG: KASAN: slab-use-after-free in check_stack_usage kernel/exit.c:849 [inline]
BUG: KASAN: slab-use-after-free in do_exit+0x1892/0x2320 kernel/exit.c:1006
Read of size 8 at addr ffffc900039c0748 by task kworker/R-ext4-/6060

CPU: 1 UID: 0 PID: 6060 Comm: kworker/R-ext4- Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 stack_not_used kernel/exit.c:800 [inline]
 check_stack_usage kernel/exit.c:849 [inline]
 do_exit+0x1892/0x2320 kernel/exit.c:1006
 kthread_exit+0x22b/0x280 kernel/kthread.c:336
 kthread+0x3a6/0x470 kernel/kthread.c:469
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

The buggy address belongs to stack of task kworker/R-ext4-/6060

The buggy address belongs to a 8-page vmalloc region starting at 0xffffc900039c0000 allocated at copy_process+0x508/0x3cf0 kernel/fork.c:2050
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11ade0
flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff)
raw: 017ff00000000000 0000000000000000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x29c2(GFP_NOWAIT|__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_ZERO), pid 2, tgid 2 (kthreadd), ts 65632032727, free_ts 57080349786
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2484
 alloc_frozen_pages_noprof mm/mempolicy.c:2555 [inline]
 alloc_pages_noprof+0xa8/0x190 mm/mempolicy.c:2575
 vm_area_alloc_pages mm/vmalloc.c:3662 [inline]
 __vmalloc_area_node mm/vmalloc.c:3876 [inline]
 __vmalloc_node_range_noprof+0x79b/0x1730 mm/vmalloc.c:4064
 __vmalloc_node_noprof+0xc2/0x100 mm/vmalloc.c:4124
 alloc_thread_stack_node kernel/fork.c:355 [inline]
 dup_task_struct+0x228/0x9a0 kernel/fork.c:924
 copy_process+0x508/0x3cf0 kernel/fork.c:2050
 kernel_clone+0x248/0x8e0 kernel/fork.c:2654
 kernel_thread+0x13f/0x1b0 kernel/fork.c:2715
 create_kthread kernel/kthread.c:490 [inline]
 kthreadd+0x4ec/0x6e0 kernel/kthread.c:848
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
page last free pid 5859 tgid 5859 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 __free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
 vfree+0x25a/0x400 mm/vmalloc.c:3479
 kcov_put kernel/kcov.c:442 [inline]
 kcov_close+0x28/0x50 kernel/kcov.c:543
 __fput+0x44f/0xa70 fs/file_table.c:469
 task_work_run+0x1d9/0x270 kernel/task_work.c:233
 exit_task_work include/linux/task_work.h:40 [inline]
 do_exit+0x69b/0x2320 kernel/exit.c:971
 do_group_exit+0x21b/0x2d0 kernel/exit.c:1112
 get_signal+0x1284/0x1330 kernel/signal.c:3034
 arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
 __exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
 exit_to_user_mode_loop+0x86/0x480 kernel/entry/common.c:98
 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
 syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
 do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffffc900039c0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffc900039c0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc900039c0700: 00 00 00 00 00 00 00 00 00 fb 1d 00 01 00 00 00
                                              ^
 ffffc900039c0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00
 ffffc900039c0800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


***

KASAN: slab-use-after-free Write in ext4_xattr_block_set

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      eb71ab2bf72260054677e348498ba995a057c463
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/fba2a0c2-e161-4ef9-a2c8-ddca4c80da09/config
C repro:   https://ci.syzbot.org/findings/6fc160a0-280f-49cf-8793-84b846dbb3d4/c_repro
syz repro: https://ci.syzbot.org/findings/6fc160a0-280f-49cf-8793-84b846dbb3d4/syz_repro

EXT4-fs (loop0): 1 truncate cleaned up
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
==================================================================
BUG: KASAN: slab-use-after-free in ext4_xattr_block_set+0x247e/0x2b00 fs/ext4/xattr.c:2163
Write of size 1024 at addr ffff888166b09d08 by task syz.0.18/5961

CPU: 0 UID: 0 PID: 5961 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 check_region_inline mm/kasan/generic.c:-1 [inline]
 kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200
 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
 ext4_xattr_block_set+0x247e/0x2b00 fs/ext4/xattr.c:2163
 ext4_xattr_move_to_block fs/ext4/xattr.c:2669 [inline]
 ext4_xattr_make_inode_space fs/ext4/xattr.c:2744 [inline]
 ext4_expand_extra_isize_ea+0x12e6/0x1eb0 fs/ext4/xattr.c:2832
 __ext4_expand_extra_isize+0x30d/0x400 fs/ext4/inode.c:6297
 ext4_try_to_expand_extra_isize fs/ext4/inode.c:6340 [inline]
 __ext4_mark_inode_dirty+0x45c/0x730 fs/ext4/inode.c:6418
 ext4_dirty_inode+0xd0/0x110 fs/ext4/inode.c:6450
 __mark_inode_dirty+0x3a4/0x1470 fs/fs-writeback.c:2609
 generic_update_time fs/inode.c:2198 [inline]
 touch_atime+0x576/0x6b0 fs/inode.c:2273
 file_accessed include/linux/fs.h:2263 [inline]
 filemap_read+0x1053/0x1230 mm/filemap.c:2872
 __kernel_read+0x504/0x9b0 fs/read_write.c:532
 integrity_kernel_read+0x89/0xd0 security/integrity/iint.c:28
 ima_calc_file_hash_tfm security/integrity/ima/ima_crypto.c:480 [inline]
 ima_calc_file_shash security/integrity/ima/ima_crypto.c:511 [inline]
 ima_calc_file_hash+0x12c3/0x17f0 security/integrity/ima/ima_crypto.c:568
 ima_collect_measurement+0x48b/0x930 security/integrity/ima/ima_api.c:295
 process_measurement+0x12cd/0x1c80 security/integrity/ima/ima_main.c:407
 ima_file_check+0xe1/0x130 security/integrity/ima/ima_main.c:667
 security_file_post_open+0xb3/0x260 security/security.c:2652
 do_open fs/namei.c:4673 [inline]
 path_openat+0x2e4d/0x3860 fs/namei.c:4830
 do_file_open+0x23e/0x4a0 fs/namei.c:4859
 do_sys_openat2+0x113/0x200 fs/open.c:1366
 do_sys_open fs/open.c:1372 [inline]
 __do_sys_openat fs/open.c:1388 [inline]
 __se_sys_openat fs/open.c:1383 [inline]
 __x64_sys_openat+0x138/0x170 fs/open.c:1383
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0bb039c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f0baf9fe028 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007f0bb0615fa0 RCX: 00007f0bb039c799
RDX: 0000000000000042 RSI: 0000200000000040 RDI: ffffffffffffff9c
RBP: 00007f0bb0432bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f0bb0616038 R14: 00007f0bb0615fa0 R15: 00007fff0f6badc8
 </TASK>

The buggy address belongs to the physical page:
page: refcount:2 mapcount:0 mapping:ffff88816785e480 index:0x8 pfn:0x166b09
memcg:ffff8881026d1b00
aops:def_blk_aops ino:700000 dentry name(?):""
flags: 0x57ff38000004a2c(referenced|uptodate|lru|workingset|owner_2|private|node=1|zone=2|lastcpupid=0x7ff)
raw: 057ff38000004a2c ffffea00069d7208 ffffea0005a8fac8 ffff88816785e480
raw: 0000000000000008 ffff888119801740 00000002ffffffff ffff8881026d1b00
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x152c40(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_HARDWALL), pid 5814, tgid 5814 (udevd), ts 66017733899, free_ts 66011346759
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2484
 alloc_frozen_pages_noprof mm/mempolicy.c:2555 [inline]
 alloc_pages_noprof+0xa8/0x190 mm/mempolicy.c:2575
 folio_alloc_noprof+0x1e/0x30 mm/mempolicy.c:2585
 filemap_alloc_folio_noprof+0x111/0x470 mm/filemap.c:1013
 ractl_alloc_folio mm/readahead.c:189 [inline]
 page_cache_ra_unbounded+0x39b/0xa50 mm/readahead.c:277
 do_page_cache_ra mm/readahead.c:334 [inline]
 force_page_cache_ra+0x26e/0x2e0 mm/readahead.c:364
 filemap_get_pages+0x4c0/0x1f10 mm/filemap.c:2690
 filemap_read+0x447/0x1230 mm/filemap.c:2800
 blkdev_read_iter+0x30a/0x440 block/fops.c:855
 new_sync_read fs/read_write.c:493 [inline]
 vfs_read+0x582/0xa70 fs/read_write.c:574
 ksys_read+0x150/0x270 fs/read_write.c:717
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5814 tgid 5814 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 free_unref_folios+0xed5/0x16d0 mm/page_alloc.c:3040
 folios_put_refs+0x789/0x8d0 mm/swap.c:1002
 folios_put include/linux/mm.h:1876 [inline]
 folio_batch_move_lru+0x39d/0x430 mm/swap.c:179
 lru_add_drain_cpu+0xb8/0x7b0 mm/swap.c:648
 lru_add_drain+0x121/0x3e0 mm/swap.c:737
 __folio_batch_release+0x48/0x90 mm/swap.c:1059
 folio_batch_release include/linux/pagevec.h:101 [inline]
 shmem_undo_range+0x52c/0x1660 mm/shmem.c:1149
 shmem_truncate_range mm/shmem.c:1277 [inline]
 shmem_evict_inode+0x240/0x9e0 mm/shmem.c:1407
 evict+0x61e/0xb10 fs/inode.c:846
 __dentry_kill+0x1a2/0x5e0 fs/dcache.c:670
 finish_dput+0xc9/0x480 fs/dcache.c:879
 end_renaming fs/namei.c:4096 [inline]
 filename_renameat2+0x61e/0x9c0 fs/namei.c:6146
 __do_sys_rename fs/namei.c:6188 [inline]
 __se_sys_rename+0x55/0x2c0 fs/namei.c:6184
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff888166b09f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888166b09f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888166b0a000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                   ^
 ffff888166b0a080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888166b0a100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


***

KASAN: use-after-free Write in ext4_xattr_block_set

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      eb71ab2bf72260054677e348498ba995a057c463
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/fba2a0c2-e161-4ef9-a2c8-ddca4c80da09/config
C repro:   https://ci.syzbot.org/findings/64472648-05ba-4d64-b168-bb54f3f15702/c_repro
syz repro: https://ci.syzbot.org/findings/64472648-05ba-4d64-b168-bb54f3f15702/syz_repro

fscrypt: AES-256-CBC-CTS using implementation "cts(cbc(ecb(aes-lib)))"
fscrypt: AES-256-XTS using implementation "xts(ecb(aes-lib))"
==================================================================
BUG: KASAN: use-after-free in ext4_xattr_block_set+0x247e/0x2b00 fs/ext4/xattr.c:2163
Write of size 4096 at addr ffff8881ba262108 by task syz.0.17/5950

CPU: 1 UID: 0 PID: 5950 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 check_region_inline mm/kasan/generic.c:-1 [inline]
 kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200
 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
 ext4_xattr_block_set+0x247e/0x2b00 fs/ext4/xattr.c:2163
 ext4_xattr_set_handle+0xe37/0x14d0 fs/ext4/xattr.c:2457
 ext4_xattr_set+0x255/0x340 fs/ext4/xattr.c:2559
 __vfs_setxattr+0x43c/0x480 fs/xattr.c:200
 __vfs_setxattr_noperm+0x12d/0x660 fs/xattr.c:234
 vfs_setxattr+0x163/0x360 fs/xattr.c:321
 ovl_do_setxattr fs/overlayfs/overlayfs.h:317 [inline]
 ovl_setxattr fs/overlayfs/overlayfs.h:329 [inline]
 ovl_verify_set_fh+0x136/0x200 fs/overlayfs/namei.c:556
 ovl_verify_origin_xattr+0x98/0x180 fs/overlayfs/namei.c:584
 ovl_verify_upper fs/overlayfs/overlayfs.h:757 [inline]
 ovl_get_indexdir+0x4aa/0x600 fs/overlayfs/super.c:898
 ovl_fill_super_creds fs/overlayfs/super.c:1478 [inline]
 ovl_fill_super+0x37f3/0x5e00 fs/overlayfs/super.c:1564
 vfs_get_super fs/super.c:1327 [inline]
 get_tree_nodev+0xbb/0x150 fs/super.c:1346
 vfs_get_tree+0x92/0x2a0 fs/super.c:1754
 fc_mount fs/namespace.c:1193 [inline]
 do_new_mount_fc fs/namespace.c:3763 [inline]
 do_new_mount+0x341/0xd30 fs/namespace.c:3839
 do_mount fs/namespace.c:4172 [inline]
 __do_sys_mount fs/namespace.c:4361 [inline]
 __se_sys_mount+0x31d/0x420 fs/namespace.c:4338
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ffbced9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd4392dda8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffbcf015fa0 RCX: 00007ffbced9c799
RDX: 0000200000000140 RSI: 0000200000000100 RDI: 0000000000000000
RBP: 00007ffbcee32bd9 R08: 0000200000000180 R09: 0000000000000000
R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffbcf015fac R14: 00007ffbcf015fa0 R15: 00007ffbcf015fa0
 </TASK>

The buggy address belongs to the physical page:
page: refcount:3 mapcount:0 mapping:ffff888107834200 index:0xe0 pfn:0x1ba262
memcg:ffff88816c071b00
aops:def_blk_aops ino:700000 dentry name(?):""
flags: 0x57ff08000004004(referenced|private|node=1|zone=2|lastcpupid=0x7ff)
raw: 057ff08000004004 0000000000000000 dead000000000122 ffff888107834200
raw: 00000000000000e0 ffff8881bc57f658 00000003ffffffff ffff88816c071b00
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Movable, gfp_mask 0x148c48(GFP_NOFS|__GFP_MOVABLE|__GFP_NOFAIL|__GFP_COMP|__GFP_HARDWALL), pid 5950, tgid 5950 (syz.0.17), ts 65596023731, free_ts 65574666721
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2484
 alloc_frozen_pages_noprof mm/mempolicy.c:2555 [inline]
 alloc_pages_noprof+0xa8/0x190 mm/mempolicy.c:2575
 folio_alloc_noprof+0x1e/0x30 mm/mempolicy.c:2585
 filemap_alloc_folio_noprof+0x111/0x470 mm/filemap.c:1013
 __filemap_get_folio_mpol+0x3fc/0xb00 mm/filemap.c:2006
 __filemap_get_folio include/linux/pagemap.h:774 [inline]
 grow_dev_folio fs/buffer.c:1047 [inline]
 grow_buffers fs/buffer.c:1113 [inline]
 __getblk_slow fs/buffer.c:1131 [inline]
 bdev_getblk+0x1f6/0x6e0 fs/buffer.c:1458
 __getblk include/linux/buffer_head.h:380 [inline]
 sb_getblk include/linux/buffer_head.h:386 [inline]
 ext4_xattr_block_set+0x1d9c/0x2b00 fs/ext4/xattr.c:2131
 ext4_xattr_set_handle+0xe37/0x14d0 fs/ext4/xattr.c:2457
 ext4_xattr_set+0x255/0x340 fs/ext4/xattr.c:2559
 __vfs_setxattr+0x43c/0x480 fs/xattr.c:200
 __vfs_setxattr_noperm+0x12d/0x660 fs/xattr.c:234
 vfs_setxattr+0x163/0x360 fs/xattr.c:321
 ovl_do_setxattr fs/overlayfs/overlayfs.h:317 [inline]
 ovl_setxattr fs/overlayfs/overlayfs.h:329 [inline]
 ovl_verify_set_fh+0x136/0x200 fs/overlayfs/namei.c:556
page last free pid 5959 tgid 5959 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 free_unref_folios+0xed5/0x16d0 mm/page_alloc.c:3040
 folios_put_refs+0x789/0x8d0 mm/swap.c:1002
 free_pages_and_swap_cache+0x537/0x5b0 mm/swap_state.c:426
 __tlb_batch_free_encoded_pages mm/mmu_gather.c:138 [inline]
 tlb_batch_pages_flush mm/mmu_gather.c:151 [inline]
 tlb_flush_mmu_free mm/mmu_gather.c:398 [inline]
 tlb_flush_mmu+0x6d3/0xa30 mm/mmu_gather.c:405
 tlb_finish_mmu+0xf9/0x230 mm/mmu_gather.c:530
 exit_mmap+0x498/0xa10 mm/mmap.c:1315
 __mmput+0x118/0x430 kernel/fork.c:1174
 exit_mm+0x168/0x220 kernel/exit.c:581
 do_exit+0x62e/0x2320 kernel/exit.c:959
 do_group_exit+0x21b/0x2d0 kernel/exit.c:1112
 __do_sys_exit_group kernel/exit.c:1123 [inline]
 __se_sys_exit_group kernel/exit.c:1121 [inline]
 __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121
 x64_sys_call+0x221a/0x2240 arch/x86/include/generated/asm/syscalls_64.h:232
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff8881ba262f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff8881ba262f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8881ba263000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff8881ba263080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff8881ba263100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


***

WARNING in ext4_xattr_block_set

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      eb71ab2bf72260054677e348498ba995a057c463
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/fba2a0c2-e161-4ef9-a2c8-ddca4c80da09/config
C repro:   https://ci.syzbot.org/findings/842bc2c4-3a27-4dcd-9ff1-64e538e1ea22/c_repro
syz repro: https://ci.syzbot.org/findings/842bc2c4-3a27-4dcd-9ff1-64e538e1ea22/syz_repro

EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
EXT4-fs (loop0): encrypted files will use data=ordered instead of data journaling mode
------------[ cut here ]------------
!PageLargeKmalloc(page)
WARNING: mm/slub.c:6371 at free_large_kmalloc+0xa3/0x140 mm/slub.c:6371, CPU#0: syz.0.17/5958
Modules linked in:
CPU: 0 UID: 0 PID: 5958 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:free_large_kmalloc+0xa3/0x140 mm/slub.c:6371
Code: f8 ff 74 17 25 00 00 00 ff 3d 00 00 00 f8 0f 85 a0 00 00 00 c7 43 30 ff ff ff ff 48 89 df 89 ee 5b 41 5e 5d e9 ee c7 fc ff 90 <0f> 0b 90 48 89 df 48 c7 c6 fb d9 f0 8d 5b 41 5e 5d e9 97 f2 03 ff
RSP: 0018:ffffc90005dff0e0 EFLAGS: 00010206
RAX: 00000000ff000000 RBX: ffffea000599df00 RCX: ffff888173089d01
RDX: 0000000000000000 RSI: ffff88816677c508 RDI: ffffea000599df00
RBP: 0000000000000000 R08: ffff888108c77063 R09: 1ffff1102118ee0c
R10: dffffc0000000000 R11: ffffed102118ee0d R12: 0000000000000000
R13: dffffc0000000000 R14: ffff88816677c508 R15: 0000000000000000
FS:  0000555583178500(0000) GS:ffff88818de63000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe5501a000 CR3: 000000017552a000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 ext4_xattr_block_set+0x2102/0x2b00 fs/ext4/xattr.c:2210
 ext4_xattr_move_to_block fs/ext4/xattr.c:2669 [inline]
 ext4_xattr_make_inode_space fs/ext4/xattr.c:2744 [inline]
 ext4_expand_extra_isize_ea+0x12e6/0x1eb0 fs/ext4/xattr.c:2832
 __ext4_expand_extra_isize+0x30d/0x400 fs/ext4/inode.c:6297
 ext4_try_to_expand_extra_isize fs/ext4/inode.c:6340 [inline]
 __ext4_mark_inode_dirty+0x45c/0x730 fs/ext4/inode.c:6418
 ext4_inline_data_truncate+0x76b/0xb40 fs/ext4/inline.c:1940
 ext4_truncate+0x3b5/0x13b0 fs/ext4/inode.c:4518
 ext4_process_orphan+0x1cb/0x300 fs/ext4/orphan.c:337
 ext4_orphan_cleanup+0xc38/0x1470 fs/ext4/orphan.c:472
 __ext4_fill_super fs/ext4/super.c:5668 [inline]
 ext4_fill_super+0x59ff/0x6320 fs/ext4/super.c:5791
 get_tree_bdev_flags+0x431/0x4f0 fs/super.c:1694
 vfs_get_tree+0x92/0x2a0 fs/super.c:1754
 fc_mount fs/namespace.c:1193 [inline]
 do_new_mount_fc fs/namespace.c:3763 [inline]
 do_new_mount+0x341/0xd30 fs/namespace.c:3839
 do_mount fs/namespace.c:4172 [inline]
 __do_sys_mount fs/namespace.c:4361 [inline]
 __se_sys_mount+0x31d/0x420 fs/namespace.c:4338
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f59e879da0a
Code: 48 c7 c2 e8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe550193e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffe55019470 RCX: 00007f59e879da0a
RDX: 0000200000000040 RSI: 00002000000001c0 RDI: 00007ffe55019430
RBP: 0000200000000040 R08: 00007ffe55019470 R09: 0000000000000404
R10: 0000000000000404 R11: 0000000000000246 R12: 00002000000001c0
R13: 00007ffe55019430 R14: 0000000000000442 R15: 0000200000000300
 </TASK>


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

[PATCH v2] ext4: avoid infinite loops caused by data conflicts

[Edward Adam Davis]

In the execution paths of mkdir and openat, there are two different
structures, struct ext4_xattr_header and struct ext4_dir_entry_2,
that both reference the same buffer head.

In the mkdir path, ext4_add_entry() first sets the rec_len member of
the struct ext4_dir_entry_2 to 2048, and then sets the file_type value
to 2 in add_dirent_to_buf()->ext4_insert_dentry()->ext4_set_de_type().

This causes the h_refcount value in the other struct ext4_xattr_header,
which references the same buffer head, to be too large in the openat
path.

The above causes ext4_xattr_block_set() to enter an infinite loop about
"inserted" and cannot release the inode lock, ultimately leading to the
143s blocking problem mentioned in [1].

When accessing the ext4_xattr_header structure in xattr, the accessed
buffer head data is placed after ext4_dir_entry_2 to prevent data
collisions caused by data overlap.

[1]
INFO: task syz.0.17:5995 blocked for more than 143 seconds.
Call Trace:
 inode_lock_nested include/linux/fs.h:1073 [inline]
 __start_dirop fs/namei.c:2923 [inline]
 start_dirop fs/namei.c:2934 [inline]

Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: fix ci reported issues

 fs/ext4/ext4.h  | 2 ++
 fs/ext4/xattr.c | 3 ++-
 fs/ext4/xattr.h | 3 ++-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 293f698b7042..4b72da4d646f 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2425,6 +2425,8 @@ struct ext4_dir_entry_2 {
 	char	name[EXT4_NAME_LEN];	/* File name */
 };
 
+#define DIFF_AREA_DE_XH sizeof(struct ext4_dir_entry_2)
+
 /*
  * Access the hashes at the end of ext4_dir_entry_2
  */
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..b7bdf8ae2b4f 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -2160,7 +2160,8 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
 				error = -EIO;
 				goto getblk_failed;
 			}
-			memcpy(new_bh->b_data, s->base, new_bh->b_size);
+			memcpy(new_bh->b_data + DIFF_AREA_DE_XH, s->base,
+			       new_bh->b_size - DIFF_AREA_DE_XH);
 			ext4_xattr_block_csum_set(inode, new_bh);
 			set_buffer_uptodate(new_bh);
 			unlock_buffer(new_bh);
diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h
index 1fedf44d4fb6..4a28023c72e8 100644
--- a/fs/ext4/xattr.h
+++ b/fs/ext4/xattr.h
@@ -8,6 +8,7 @@
 */
 
 #include <linux/xattr.h>
+#include "ext4.h"
 
 /* Magic value in attribute blocks */
 #define EXT4_XATTR_MAGIC		0xEA020000
@@ -90,7 +91,7 @@ struct ext4_xattr_entry {
 #define EXT4_XATTR_MIN_LARGE_EA_SIZE(b)					\
 	((b) - EXT4_XATTR_LEN(3) - sizeof(struct ext4_xattr_header) - 4)
 
-#define BHDR(bh) ((struct ext4_xattr_header *)((bh)->b_data))
+#define BHDR(bh) ((struct ext4_xattr_header *)((bh)->b_data + DIFF_AREA_DE_XH))
 #define ENTRY(ptr) ((struct ext4_xattr_entry *)(ptr))
 #define BFIRST(bh) ENTRY(BHDR(bh)+1)
 #define IS_LAST_ENTRY(entry) (*(__u32 *)(entry) == 0)
-- 
2.43.0

Re: [PATCH] ext4: avoid infinite loops caused by data conflicts

[Jan Kara]

On Sun 01-03-26 18:12:47, Edward Adam Davis wrote:
> In the execution paths of mkdir and openat, there are two different
> structures, struct ext4_xattr_header and struct ext4_dir_entry_2,
> that both reference the same buffer head.
> 
> In the mkdir path, ext4_add_entry() first sets the rec_len member of
> the struct ext4_dir_entry_2 to 2048, and then sets the file_type value
> to 2 in add_dirent_to_buf()->ext4_insert_dentry()->ext4_set_de_type().

If I understand it right, the filesystem is corrupted so that directory
block of some directory is also pointed to as xattr block of some inode.
The right question to investigate here is why the block passed validation
as both xattr block and directory block - that needs explanation. Likely
metadata checksums were disabled and with some effort we could then create
a block that will be both valid directory block and valid xattr block. If
that is indeed the case, this is game over and we can't fix this in ext4
(the kernel just doesn't have enough resources to validate against such
cases) - enable metadata checksums if you need to protect against such
corruptions.

Your attempt at a "fix" changes the on disk filesystem format. I don't
think you've put too much thought into that, did you?

								Honza

> This causes the h_refcount value in the other struct ext4_xattr_header,
> which references the same buffer head, to be too large in the openat
> path.
> 
> The above causes ext4_xattr_block_set() to enter an infinite loop about
> "inserted" and cannot release the inode lock, ultimately leading to the
> 143s blocking problem mentioned in [1].
> 
> When accessing the ext4_xattr_header structure in xattr, the accessed
> buffer head data is placed after ext4_dir_entry_2 to prevent data
> collisions caused by data overlap.
> 
> [1]
> INFO: task syz.0.17:5995 blocked for more than 143 seconds.
> Call Trace:
>  inode_lock_nested include/linux/fs.h:1073 [inline]
>  __start_dirop fs/namei.c:2923 [inline]
>  start_dirop fs/namei.c:2934 [inline]
> 
> Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
> Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
> Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>  fs/ext4/ext4.h  | 2 ++
>  fs/ext4/xattr.c | 2 +-
>  fs/ext4/xattr.h | 3 ++-
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 293f698b7042..4b72da4d646f 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -2425,6 +2425,8 @@ struct ext4_dir_entry_2 {
>  	char	name[EXT4_NAME_LEN];	/* File name */
>  };
>  
> +#define DIFF_AREA_DE_XH sizeof(struct ext4_dir_entry_2)
> +
>  /*
>   * Access the hashes at the end of ext4_dir_entry_2
>   */
> diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> index 7bf9ba19a89d..313c460a93c5 100644
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -2160,7 +2160,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
>  				error = -EIO;
>  				goto getblk_failed;
>  			}
> -			memcpy(new_bh->b_data, s->base, new_bh->b_size);
> +			memcpy(new_bh->b_data + DIFF_AREA_DE_XH, s->base, new_bh->b_size);
>  			ext4_xattr_block_csum_set(inode, new_bh);
>  			set_buffer_uptodate(new_bh);
>  			unlock_buffer(new_bh);
> diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h
> index 1fedf44d4fb6..4a28023c72e8 100644
> --- a/fs/ext4/xattr.h
> +++ b/fs/ext4/xattr.h
> @@ -8,6 +8,7 @@
>  */
>  
>  #include <linux/xattr.h>
> +#include "ext4.h"
>  
>  /* Magic value in attribute blocks */
>  #define EXT4_XATTR_MAGIC		0xEA020000
> @@ -90,7 +91,7 @@ struct ext4_xattr_entry {
>  #define EXT4_XATTR_MIN_LARGE_EA_SIZE(b)					\
>  	((b) - EXT4_XATTR_LEN(3) - sizeof(struct ext4_xattr_header) - 4)
>  
> -#define BHDR(bh) ((struct ext4_xattr_header *)((bh)->b_data))
> +#define BHDR(bh) ((struct ext4_xattr_header *)((bh)->b_data + DIFF_AREA_DE_XH))
>  #define ENTRY(ptr) ((struct ext4_xattr_entry *)(ptr))
>  #define BFIRST(bh) ENTRY(BHDR(bh)+1)
>  #define IS_LAST_ENTRY(entry) (*(__u32 *)(entry) == 0)
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[syzbot ci] Re: ext4: avoid infinite loops caused by data conflicts

[syzbot ci]

syzbot ci has tested the following series

[v2] ext4: avoid infinite loops caused by data conflicts
https://lore.kernel.org/all/tencent_13E236704A527419766767443D6736EE9609@qq.com
* [PATCH v2] ext4: avoid infinite loops caused by data conflicts

and found the following issues:
* KASAN: slab-out-of-bounds Read in ext4_xattr_block_csum_set
* KASAN: slab-use-after-free Read in ext4_xattr_block_csum_set
* KASAN: slab-use-after-free Read in ext4_xattr_set_entry
* KASAN: use-after-free Read in ext4_xattr_block_csum_set
* KASAN: use-after-free Read in ext4_xattr_set_entry

Full report is available here:
https://ci.syzbot.org/series/ccbb03e4-9312-48f0-808d-923f86d83f2f

***

KASAN: slab-out-of-bounds Read in ext4_xattr_block_csum_set

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      11439c4635edd669ae435eec308f4ab8a0804808
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
syz repro: https://ci.syzbot.org/findings/ddaf8105-c8d7-4a57-87ef-ee750875c5c7/syz_repro

fscrypt: AES-256-CBC-CTS using implementation "cts(cbc(ecb(aes-lib)))"
==================================================================
BUG: KASAN: slab-out-of-bounds in crc32c_base lib/crc/crc32-main.c:54 [inline]
BUG: KASAN: slab-out-of-bounds in crc32c_arch lib/crc/x86/crc32.h:44 [inline]
BUG: KASAN: slab-out-of-bounds in crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
Read of size 1 at addr ffff88816a0ea0b0 by task syz.0.17/6006

CPU: 1 UID: 0 PID: 6006 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 crc32c_base lib/crc/crc32-main.c:54 [inline]
 crc32c_arch lib/crc/x86/crc32.h:44 [inline]
 crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
 ext4_chksum fs/ext4/ext4.h:2553 [inline]
 ext4_xattr_block_csum fs/ext4/xattr.c:147 [inline]
 ext4_xattr_block_csum_set+0x241/0x330 fs/ext4/xattr.c:172
 ext4_xattr_block_set+0x2494/0x2b00 fs/ext4/xattr.c:2165
 ext4_xattr_set_handle+0xe37/0x14d0 fs/ext4/xattr.c:2458
 ext4_set_context+0x233/0x560 fs/ext4/crypto.c:166
 fscrypt_set_context+0x397/0x460 fs/crypto/policy.c:791
 __ext4_new_inode+0x3158/0x3d20 fs/ext4/ialloc.c:1314
 ext4_mkdir+0x3da/0xbf0 fs/ext4/namei.c:3005
 vfs_mkdir+0x413/0x630 fs/namei.c:5233
 filename_mkdirat+0x285/0x510 fs/namei.c:5266
 __do_sys_mkdirat fs/namei.c:5287 [inline]
 __se_sys_mkdirat+0x35/0x150 fs/namei.c:5284
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb60ad9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb60bd17028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007fb60b015fa0 RCX: 00007fb60ad9c799
RDX: 00000000000001c0 RSI: 0000200000000180 RDI: ffffffffffffff9c
RBP: 00007fb60ae32bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb60b016038 R14: 00007fb60b015fa0 R15: 00007fff4bbf7228
 </TASK>

Allocated by task 1:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 unpoison_slab_object mm/kasan/common.c:340 [inline]
 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
 kasan_slab_alloc include/linux/kasan.h:253 [inline]
 slab_post_alloc_hook mm/slub.c:4515 [inline]
 slab_alloc_node mm/slub.c:4844 [inline]
 kmem_cache_alloc_noprof+0x2bc/0x650 mm/slub.c:4851
 __kernfs_new_node+0xe9/0x8e0 fs/kernfs/dir.c:637
 kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:718
 __kernfs_create_file+0x4b/0x2e0 fs/kernfs/file.c:1057
 sysfs_add_file_mode_ns+0x238/0x300 fs/sysfs/file.c:313
 create_files fs/sysfs/group.c:82 [inline]
 internal_create_group+0x673/0x1180 fs/sysfs/group.c:189
 internal_create_groups fs/sysfs/group.c:229 [inline]
 sysfs_create_groups+0x59/0x120 fs/sysfs/group.c:255
 device_add_groups drivers/base/core.c:2836 [inline]
 device_add_attrs+0xdd/0x5b0 drivers/base/core.c:2900
 device_add+0x496/0xb70 drivers/base/core.c:3643
 __video_register_device+0x3e40/0x4d20 drivers/media/v4l2-core/v4l2-dev.c:1076
 video_register_device include/media/v4l2-dev.h:390 [inline]
 vivid_create_devnodes+0xc5e/0x2bf0 drivers/media/test-drivers/vivid/vivid-core.c:1471
 vivid_create_instance drivers/media/test-drivers/vivid/vivid-core.c:2042 [inline]
 vivid_probe+0x510d/0x72b0 drivers/media/test-drivers/vivid/vivid-core.c:2095
 platform_probe+0xf9/0x190 drivers/base/platform.c:1446
 call_driver_probe drivers/base/dd.c:-1 [inline]
 really_probe+0x267/0xaf0 drivers/base/dd.c:661
 __driver_probe_device+0x18c/0x320 drivers/base/dd.c:803
 driver_probe_device+0x4f/0x240 drivers/base/dd.c:833
 __driver_attach+0x3e7/0x710 drivers/base/dd.c:1227
 bus_for_each_dev+0x23b/0x2c0 drivers/base/bus.c:383
 bus_add_driver+0x345/0x670 drivers/base/bus.c:715
 driver_register+0x23a/0x320 drivers/base/driver.c:249
 vivid_init+0x561/0x5f0 drivers/media/test-drivers/vivid/vivid-core.c:2294
 do_one_initcall+0x250/0x8d0 init/main.c:1382
 do_initcall_level+0x104/0x190 init/main.c:1444
 do_initcalls+0x59/0xa0 init/main.c:1460
 kernel_init_freeable+0x2a6/0x3e0 init/main.c:1692
 kernel_init+0x1d/0x1d0 init/main.c:1582
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

The buggy address belongs to the object at ffff88816a0ea000
 which belongs to the cache kernfs_node_cache of size 176
The buggy address is located 0 bytes to the right of
 allocated 176-byte region [ffff88816a0ea000, ffff88816a0ea0b0)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x16a0ea
flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 057ff00000000000 ffff8881012d3dc0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000800110011 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 19200276917, free_ts 4632825873
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_slab_page mm/slub.c:3269 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3458
 new_slab mm/slub.c:3516 [inline]
 refill_objects+0x331/0x3c0 mm/slub.c:7153
 refill_sheaf mm/slub.c:2818 [inline]
 __pcs_replace_empty_main+0x2b9/0x620 mm/slub.c:4592
 alloc_from_pcs mm/slub.c:4695 [inline]
 slab_alloc_node mm/slub.c:4829 [inline]
 kmem_cache_alloc_noprof+0x37d/0x650 mm/slub.c:4851
 __kernfs_new_node+0xe9/0x8e0 fs/kernfs/dir.c:637
 kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:718
 kernfs_create_link+0xa7/0x200 fs/kernfs/symlink.c:39
 sysfs_do_create_link_sd+0x83/0x110 fs/sysfs/symlink.c:44
 device_create_sys_dev_entry+0x122/0x190 drivers/base/core.c:3515
 device_add+0x733/0xb70 drivers/base/core.c:3659
 cdev_device_add+0x1d6/0x390 fs/char_dev.c:553
 media_devnode_register+0x287/0x420 drivers/media/mc/mc-devnode.c:247
 __media_device_register+0x15c/0x3c0 drivers/media/mc/mc-device.c:753
page last free pid 10 tgid 10 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 __free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
 vfree+0x25a/0x400 mm/vmalloc.c:3479
 delayed_vfree_work+0x55/0x80 mm/vmalloc.c:3398
 process_one_work kernel/workqueue.c:3275 [inline]
 process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
 worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
 kthread+0x388/0x470 kernel/kthread.c:467
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
 ffff88816a0e9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88816a0ea000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88816a0ea080: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc 00 00
                                     ^
 ffff88816a0ea100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88816a0ea180: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00
==================================================================


***

KASAN: slab-use-after-free Read in ext4_xattr_block_csum_set

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      11439c4635edd669ae435eec308f4ab8a0804808
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
C repro:   https://ci.syzbot.org/findings/bee8f041-a020-4e43-a068-e014486583d9/c_repro
syz repro: https://ci.syzbot.org/findings/bee8f041-a020-4e43-a068-e014486583d9/syz_repro

ext4 filesystem being mounted at /0/file0 supports timestamps until 2038-01-19 (0x7fffffff)
fscrypt: AES-256-CBC-CTS using implementation "cts(cbc(ecb(aes-lib)))"
==================================================================
BUG: KASAN: slab-use-after-free in crc32c_base lib/crc/crc32-main.c:54 [inline]
BUG: KASAN: slab-use-after-free in crc32c_arch lib/crc/x86/crc32.h:44 [inline]
BUG: KASAN: slab-use-after-free in crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
Read of size 1 at addr ffff88816c2f9000 by task syz.0.17/5966

CPU: 0 UID: 0 PID: 5966 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 crc32c_base lib/crc/crc32-main.c:54 [inline]
 crc32c_arch lib/crc/x86/crc32.h:44 [inline]
 crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
 ext4_chksum fs/ext4/ext4.h:2553 [inline]
 ext4_xattr_block_csum fs/ext4/xattr.c:147 [inline]
 ext4_xattr_block_csum_set+0x241/0x330 fs/ext4/xattr.c:172
 ext4_xattr_block_set+0x2494/0x2b00 fs/ext4/xattr.c:2165
 ext4_xattr_set_handle+0xe37/0x14d0 fs/ext4/xattr.c:2458
 ext4_set_context+0x233/0x560 fs/ext4/crypto.c:166
 fscrypt_set_context+0x397/0x460 fs/crypto/policy.c:791
 __ext4_new_inode+0x3158/0x3d20 fs/ext4/ialloc.c:1314
 ext4_mkdir+0x3da/0xbf0 fs/ext4/namei.c:3005
 vfs_mkdir+0x413/0x630 fs/namei.c:5233
 filename_mkdirat+0x285/0x510 fs/namei.c:5266
 __do_sys_mkdir fs/namei.c:5293 [inline]
 __se_sys_mkdir+0x34/0x150 fs/namei.c:5290
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb91ff9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe3b8b33f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00007fb920215fa0 RCX: 00007fb91ff9c799
RDX: 0000000000000000 RSI: 0000000000000142 RDI: 0000200000000300
RBP: 00007fb920032bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb920215fac R14: 00007fb920215fa0 R15: 00007fb920215fa0
 </TASK>

Allocated by task 5807:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
 __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
 kasan_kmalloc include/linux/kasan.h:263 [inline]
 __kmalloc_cache_noprof+0x31c/0x660 mm/slub.c:5358
 kmalloc_noprof include/linux/slab.h:950 [inline]
 slab_free_hook mm/slub.c:2644 [inline]
 slab_free mm/slub.c:6143 [inline]
 kmem_cache_free+0x15b/0x630 mm/slub.c:6273
 anon_vma_free mm/rmap.c:137 [inline]
 __put_anon_vma+0x12b/0x2d0 mm/rmap.c:2889
 put_anon_vma mm/internal.h:215 [inline]
 unlink_anon_vmas+0x58b/0x730 mm/rmap.c:529
 free_pgtables+0x663/0xb70 mm/memory.c:414
 exit_mmap+0x490/0xa10 mm/mmap.c:1314
 __mmput+0x118/0x430 kernel/fork.c:1174
 exec_mmap+0x3b4/0x440 fs/exec.c:893
 begin_new_exec+0x134a/0x24a0 fs/exec.c:1148
 load_elf_binary+0xa47/0x2980 fs/binfmt_elf.c:1011
 search_binary_handler fs/exec.c:1664 [inline]
 exec_binprm fs/exec.c:1696 [inline]
 bprm_execve+0x93d/0x1460 fs/exec.c:1748
 do_execveat_common+0x50d/0x690 fs/exec.c:1846
 __do_sys_execve fs/exec.c:1930 [inline]
 __se_sys_execve fs/exec.c:1924 [inline]
 __x64_sys_execve+0x97/0xc0 fs/exec.c:1924
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 5807:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
 poison_slab_object mm/kasan/common.c:253 [inline]
 __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
 kasan_slab_free include/linux/kasan.h:235 [inline]
 slab_free_hook mm/slub.c:2692 [inline]
 slab_free mm/slub.c:6143 [inline]
 kfree+0x1c1/0x630 mm/slub.c:6461
 slab_free_after_rcu_debug+0x5e/0x220 mm/slub.c:6195
 rcu_do_batch kernel/rcu/tree.c:2617 [inline]
 rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
 handle_softirqs+0x22a/0x870 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 invoke_softirq kernel/softirq.c:496 [inline]
 __irq_exit_rcu+0x5f/0x150 kernel/softirq.c:723
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
 sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1056
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697

Last potentially related work creation:
 kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
 kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
 __call_rcu_common kernel/rcu/tree.c:3131 [inline]
 call_rcu+0xee/0x890 kernel/rcu/tree.c:3251
 slab_free_hook mm/slub.c:2656 [inline]
 slab_free mm/slub.c:6143 [inline]
 kmem_cache_free+0x439/0x630 mm/slub.c:6273
 anon_vma_free mm/rmap.c:137 [inline]
 __put_anon_vma+0x12b/0x2d0 mm/rmap.c:2889
 put_anon_vma mm/internal.h:215 [inline]
 unlink_anon_vmas+0x58b/0x730 mm/rmap.c:529
 free_pgtables+0x663/0xb70 mm/memory.c:414
 exit_mmap+0x490/0xa10 mm/mmap.c:1314
 __mmput+0x118/0x430 kernel/fork.c:1174
 exec_mmap+0x3b4/0x440 fs/exec.c:893
 begin_new_exec+0x134a/0x24a0 fs/exec.c:1148
 load_elf_binary+0xa47/0x2980 fs/binfmt_elf.c:1011
 search_binary_handler fs/exec.c:1664 [inline]
 exec_binprm fs/exec.c:1696 [inline]
 bprm_execve+0x93d/0x1460 fs/exec.c:1748
 do_execveat_common+0x50d/0x690 fs/exec.c:1846
 __do_sys_execve fs/exec.c:1930 [inline]
 __se_sys_execve fs/exec.c:1924 [inline]
 __x64_sys_execve+0x97/0xc0 fs/exec.c:1924
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff88816c2f9000
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes inside of
 freed 32-byte region [ffff88816c2f9000, ffff88816c2f9020)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x16c2f9
flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 057ff00000000000 ffff888100041780 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800400040 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5807, tgid 5807 (sshd), ts 57508476883, free_ts 57508008939
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_slab_page mm/slub.c:3269 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3458
 new_slab mm/slub.c:3516 [inline]
 refill_objects+0x331/0x3c0 mm/slub.c:7153
 refill_sheaf mm/slub.c:2818 [inline]
 __pcs_replace_empty_main+0x2b9/0x620 mm/slub.c:4592
 alloc_from_pcs mm/slub.c:4695 [inline]
 slab_alloc_node mm/slub.c:4829 [inline]
 __do_kmalloc_node mm/slub.c:5237 [inline]
 __kvmalloc_node_noprof+0x657/0x8a0 mm/slub.c:6730
 proc_sys_call_handler+0x3d1/0x830 fs/proc/proc_sysctl.c:583
 new_sync_read fs/read_write.c:493 [inline]
 vfs_read+0x582/0xa70 fs/read_write.c:574
 ksys_read+0x150/0x270 fs/read_write.c:717
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5807 tgid 5807 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 __free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
 tlb_batch_list_free mm/mmu_gather.c:161 [inline]
 tlb_finish_mmu+0x144/0x230 mm/mmu_gather.c:533
 unmap_region+0x2a5/0x330 mm/vma.c:488
 vms_clear_ptes mm/vma.c:1284 [inline]
 vms_complete_munmap_vmas+0x493/0xc60 mm/vma.c:1326
 do_vmi_align_munmap+0x3b7/0x4b0 mm/vma.c:1585
 do_vmi_munmap+0x252/0x2d0 mm/vma.c:1633
 __vm_munmap+0x22c/0x3d0 mm/vma.c:3254
 __do_sys_munmap mm/mmap.c:1078 [inline]
 __se_sys_munmap mm/mmap.c:1075 [inline]
 __x64_sys_munmap+0x60/0x70 mm/mmap.c:1075
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff88816c2f8f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88816c2f8f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88816c2f9000: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
                   ^
 ffff88816c2f9080: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
 ffff88816c2f9100: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
==================================================================


***

KASAN: slab-use-after-free Read in ext4_xattr_set_entry

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      11439c4635edd669ae435eec308f4ab8a0804808
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
syz repro: https://ci.syzbot.org/findings/703aaa0c-3de2-4301-b1d3-6310fbf18b70/syz_repro

==================================================================
BUG: KASAN: slab-use-after-free in ext4_xattr_set_entry+0x179e/0x1e20 fs/ext4/xattr.c:1740
Read of size 260 at addr ffff88811a37e000 by task syz.2.19/5991

CPU: 0 UID: 0 PID: 5991 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 check_region_inline mm/kasan/generic.c:-1 [inline]
 kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200
 __asan_memmove+0x29/0x70 mm/kasan/shadow.c:94
 ext4_xattr_set_entry+0x179e/0x1e20 fs/ext4/xattr.c:1740
 ext4_xattr_block_set+0x636/0x2b00 fs/ext4/xattr.c:1961
 ext4_xattr_set_handle+0xdc2/0x14d0 fs/ext4/xattr.c:2432
 ext4_xattr_set+0x255/0x340 fs/ext4/xattr.c:2560
 __vfs_removexattr+0x431/0x470 fs/xattr.c:518
 __vfs_removexattr_locked+0xe2/0x280 fs/xattr.c:553
 vfs_removexattr+0x7f/0x230 fs/xattr.c:575
 ovl_do_removexattr fs/overlayfs/overlayfs.h:335 [inline]
 ovl_removexattr fs/overlayfs/overlayfs.h:343 [inline]
 ovl_make_workdir fs/overlayfs/super.c:760 [inline]
 ovl_get_workdir fs/overlayfs/super.c:840 [inline]
 ovl_fill_super_creds fs/overlayfs/super.c:1453 [inline]
 ovl_fill_super+0x4c09/0x5e00 fs/overlayfs/super.c:1564
 vfs_get_super fs/super.c:1327 [inline]
 get_tree_nodev+0xbb/0x150 fs/super.c:1346
 vfs_get_tree+0x92/0x2a0 fs/super.c:1754
 fc_mount fs/namespace.c:1193 [inline]
 do_new_mount_fc fs/namespace.c:3763 [inline]
 do_new_mount+0x341/0xd30 fs/namespace.c:3839
 do_mount fs/namespace.c:4172 [inline]
 __do_sys_mount fs/namespace.c:4361 [inline]
 __se_sys_mount+0x31d/0x420 fs/namespace.c:4338
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7facfdf9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007facfd5fe028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007facfe215fa0 RCX: 00007facfdf9c799
RDX: 0000200000000440 RSI: 0000200000000100 RDI: 0000000000000000
RBP: 00007facfe032bd9 R08: 0000200000000280 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007facfe216038 R14: 00007facfe215fa0 R15: 00007ffdb6825fe8
 </TASK>

Allocated by task 5825:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 unpoison_slab_object mm/kasan/common.c:340 [inline]
 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
 kasan_slab_alloc include/linux/kasan.h:253 [inline]
 slab_post_alloc_hook mm/slub.c:4515 [inline]
 slab_alloc_node mm/slub.c:4844 [inline]
 kmem_cache_alloc_noprof+0x2bc/0x650 mm/slub.c:4851
 __kernfs_new_node+0xe9/0x8e0 fs/kernfs/dir.c:637
 kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:718
 __kernfs_create_file+0x4b/0x2e0 fs/kernfs/file.c:1057
 sysfs_add_file_mode_ns+0x238/0x300 fs/sysfs/file.c:313
 create_files fs/sysfs/group.c:82 [inline]
 internal_create_group+0x673/0x1180 fs/sysfs/group.c:189
 internal_create_groups fs/sysfs/group.c:229 [inline]
 sysfs_create_groups+0x59/0x120 fs/sysfs/group.c:255
 device_add_groups drivers/base/core.c:2836 [inline]
 device_add_attrs+0xdd/0x5b0 drivers/base/core.c:2900
 device_add+0x496/0xb70 drivers/base/core.c:3643
 netdev_register_kobject+0x178/0x310 net/core/net-sysfs.c:2358
 register_netdevice+0x12c0/0x1cf0 net/core/dev.c:11422
 __ip_tunnel_create+0x3e8/0x560 net/ipv4/ip_tunnel.c:268
 ip_tunnel_init_net+0x2e7/0x840 net/ipv4/ip_tunnel.c:1147
 ops_init+0x35c/0x5c0 net/core/net_namespace.c:137
 setup_net+0x118/0x340 net/core/net_namespace.c:446
 copy_net_ns+0x50e/0x730 net/core/net_namespace.c:581
 create_new_namespaces+0x3e7/0x6a0 kernel/nsproxy.c:130
 unshare_nsproxy_namespaces+0x11a/0x160 kernel/nsproxy.c:226
 ksys_unshare+0x51d/0x930 kernel/fork.c:3174
 __do_sys_unshare kernel/fork.c:3245 [inline]
 __se_sys_unshare kernel/fork.c:3243 [inline]
 __x64_sys_unshare+0x38/0x50 kernel/fork.c:3243
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 15:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
 poison_slab_object mm/kasan/common.c:253 [inline]
 __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
 kasan_slab_free include/linux/kasan.h:235 [inline]
 slab_free_hook mm/slub.c:2692 [inline]
 slab_free mm/slub.c:6143 [inline]
 kmem_cache_free+0x187/0x630 mm/slub.c:6273
 rcu_do_batch kernel/rcu/tree.c:2617 [inline]
 rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869
 handle_softirqs+0x22a/0x870 kernel/softirq.c:622
 run_ksoftirqd+0x36/0x60 kernel/softirq.c:1063
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:467
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Last potentially related work creation:
 kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
 kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
 __call_rcu_common kernel/rcu/tree.c:3131 [inline]
 call_rcu+0xee/0x890 kernel/rcu/tree.c:3251
 kernfs_put+0x18e/0x470 fs/kernfs/dir.c:591
 kernfs_remove_by_name_ns+0xb7/0x130 fs/kernfs/dir.c:1723
 kernfs_remove_by_name include/linux/kernfs.h:633 [inline]
 remove_files fs/sysfs/group.c:28 [inline]
 sysfs_remove_group+0xfc/0x2e0 fs/sysfs/group.c:328
 sysfs_remove_groups+0x54/0xb0 fs/sysfs/group.c:352
 device_remove_groups drivers/base/core.c:2843 [inline]
 device_remove_attrs+0x229/0x280 drivers/base/core.c:2979
 device_del+0x51f/0x8f0 drivers/base/core.c:3877
 unregister_netdevice_many_notify+0x1e0e/0x2370 net/core/dev.c:12447
 ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]
 ops_undo_list+0x3d3/0x940 net/core/net_namespace.c:248
 cleanup_net+0x56b/0x800 net/core/net_namespace.c:704
 process_one_work kernel/workqueue.c:3275 [inline]
 process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
 worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
 kthread+0x388/0x470 kernel/kthread.c:467
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

The buggy address belongs to the object at ffff88811a37e000
 which belongs to the cache kernfs_node_cache of size 176
The buggy address is located 0 bytes inside of
 freed 176-byte region [ffff88811a37e000, ffff88811a37e0b0)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88811a37ee10 pfn:0x11a37e
flags: 0x17ff00000000200(workingset|node=0|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 017ff00000000200 ffff8881012d3dc0 ffffea000468fed0 ffffea000468df10
raw: ffff88811a37ee10 000000080011000a 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5822, tgid 5822 (syz-executor), ts 67128981798, free_ts 62919905097
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_slab_page mm/slub.c:3269 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3458
 new_slab mm/slub.c:3516 [inline]
 refill_objects+0x331/0x3c0 mm/slub.c:7153
 refill_sheaf mm/slub.c:2818 [inline]
 __pcs_replace_empty_main+0x2b9/0x620 mm/slub.c:4592
 alloc_from_pcs mm/slub.c:4695 [inline]
 slab_alloc_node mm/slub.c:4829 [inline]
 kmem_cache_alloc_noprof+0x37d/0x650 mm/slub.c:4851
 __kernfs_new_node+0xe9/0x8e0 fs/kernfs/dir.c:637
 kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:718
 __kernfs_create_file+0x4b/0x2e0 fs/kernfs/file.c:1057
 sysfs_add_file_mode_ns+0x238/0x300 fs/sysfs/file.c:313
 create_files fs/sysfs/group.c:82 [inline]
 internal_create_group+0x673/0x1180 fs/sysfs/group.c:189
 internal_create_groups fs/sysfs/group.c:229 [inline]
 sysfs_create_groups+0x59/0x120 fs/sysfs/group.c:255
 device_add_groups drivers/base/core.c:2836 [inline]
 device_add_attrs+0x1bf/0x5b0 drivers/base/core.c:2911
 device_add+0x496/0xb70 drivers/base/core.c:3643
 netdev_register_kobject+0x178/0x310 net/core/net-sysfs.c:2358
page last free pid 5809 tgid 5809 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 __free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
 vfree+0x25a/0x400 mm/vmalloc.c:3479
 kcov_put kernel/kcov.c:442 [inline]
 kcov_close+0x28/0x50 kernel/kcov.c:543
 __fput+0x44f/0xa70 fs/file_table.c:469
 fput_close_sync+0x11f/0x240 fs/file_table.c:574
 __do_sys_close fs/open.c:1509 [inline]
 __se_sys_close fs/open.c:1494 [inline]
 __x64_sys_close+0x7e/0x110 fs/open.c:1494
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff88811a37df00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88811a37df80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88811a37e000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                   ^
 ffff88811a37e080: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fa fb
 ffff88811a37e100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


***

KASAN: use-after-free Read in ext4_xattr_block_csum_set

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      11439c4635edd669ae435eec308f4ab8a0804808
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
C repro:   https://ci.syzbot.org/findings/e7360798-7b84-42ba-9afb-319d10454142/c_repro
syz repro: https://ci.syzbot.org/findings/e7360798-7b84-42ba-9afb-319d10454142/syz_repro

fscrypt: AES-256-CBC-CTS using implementation "cts(cbc(ecb(aes-lib)))"
fscrypt: AES-256-XTS using implementation "xts(ecb(aes-lib))"
==================================================================
BUG: KASAN: use-after-free in crc32c_base lib/crc/crc32-main.c:54 [inline]
BUG: KASAN: use-after-free in crc32c_arch lib/crc/x86/crc32.h:44 [inline]
BUG: KASAN: use-after-free in crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
Read of size 1 at addr ffff88811f068000 by task syz.0.17/5956

CPU: 0 UID: 0 PID: 5956 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 crc32c_base lib/crc/crc32-main.c:54 [inline]
 crc32c_arch lib/crc/x86/crc32.h:44 [inline]
 crc32c+0x3cc/0x470 lib/crc/crc32-main.c:86
 ext4_chksum fs/ext4/ext4.h:2553 [inline]
 ext4_xattr_block_csum fs/ext4/xattr.c:147 [inline]
 ext4_xattr_block_csum_set+0x241/0x330 fs/ext4/xattr.c:172
 ext4_xattr_block_set+0x2494/0x2b00 fs/ext4/xattr.c:2165
 ext4_xattr_set_handle+0xe37/0x14d0 fs/ext4/xattr.c:2458
 ext4_set_context+0x233/0x560 fs/ext4/crypto.c:166
 fscrypt_set_context+0x397/0x460 fs/crypto/policy.c:791
 __ext4_new_inode+0x3158/0x3d20 fs/ext4/ialloc.c:1314
 ext4_create+0x233/0x470 fs/ext4/namei.c:2820
 lookup_open fs/namei.c:4483 [inline]
 open_last_lookups fs/namei.c:4583 [inline]
 path_openat+0x1395/0x3860 fs/namei.c:4827
 do_file_open+0x23e/0x4a0 fs/namei.c:4859
 do_sys_openat2+0x113/0x200 fs/open.c:1366
 do_sys_open fs/open.c:1372 [inline]
 __do_sys_openat fs/open.c:1388 [inline]
 __se_sys_openat fs/open.c:1383 [inline]
 __x64_sys_openat+0x138/0x170 fs/open.c:1383
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb6f179c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb6f26cf028 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007fb6f1a15fa0 RCX: 00007fb6f179c799
RDX: 0000000000101042 RSI: 00002000000002c0 RDI: ffffffffffffff9c
RBP: 00007fb6f1832bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb6f1a16038 R14: 00007fb6f1a15fa0 R15: 00007ffe4cb28f88
 </TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xc1 pfn:0x11f068
flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff)
raw: 017ff00000000000 ffffea00047c0f08 ffffea00047c1648 0000000000000000
raw: 00000000000000c1 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Movable, gfp_mask 0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), pid 5966, tgid 5966 (modprobe), ts 74332946165, free_ts 74344928310
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2484
 folio_alloc_mpol_noprof mm/mempolicy.c:2503 [inline]
 vma_alloc_folio_noprof+0xea/0x210 mm/mempolicy.c:2538
 folio_prealloc mm/memory.c:-1 [inline]
 do_cow_fault mm/memory.c:5822 [inline]
 do_fault mm/memory.c:5934 [inline]
 do_pte_missing+0x4ea/0x3750 mm/memory.c:4477
 handle_pte_fault mm/memory.c:6316 [inline]
 __handle_mm_fault mm/memory.c:6454 [inline]
 handle_mm_fault+0x1bec/0x3310 mm/memory.c:6623
 do_user_addr_fault+0xa73/0x1340 arch/x86/mm/fault.c:1334
 handle_page_fault arch/x86/mm/fault.c:1474 [inline]
 exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
page last free pid 5966 tgid 5966 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 free_unref_folios+0xed5/0x16d0 mm/page_alloc.c:3040
 folios_put_refs+0x789/0x8d0 mm/swap.c:1002
 free_pages_and_swap_cache+0x2e7/0x5b0 mm/swap_state.c:423
 __tlb_batch_free_encoded_pages mm/mmu_gather.c:138 [inline]
 tlb_batch_pages_flush mm/mmu_gather.c:151 [inline]
 tlb_flush_mmu_free mm/mmu_gather.c:398 [inline]
 tlb_flush_mmu+0x6d3/0xa30 mm/mmu_gather.c:405
 tlb_finish_mmu+0xf9/0x230 mm/mmu_gather.c:530
 exit_mmap+0x498/0xa10 mm/mmap.c:1315
 __mmput+0x118/0x430 kernel/fork.c:1174
 exit_mm+0x168/0x220 kernel/exit.c:581
 do_exit+0x62e/0x2320 kernel/exit.c:959
 do_group_exit+0x21b/0x2d0 kernel/exit.c:1112
 __do_sys_exit_group kernel/exit.c:1123 [inline]
 __se_sys_exit_group kernel/exit.c:1121 [inline]
 __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121
 x64_sys_call+0x221a/0x2240 arch/x86/include/generated/asm/syscalls_64.h:232
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff88811f067f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88811f067f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88811f068000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff88811f068080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88811f068100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


***

KASAN: use-after-free Read in ext4_xattr_set_entry

tree:      torvalds
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base:      11439c4635edd669ae435eec308f4ab8a0804808
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/330c6289-adc9-452b-b12f-000d32045593/config
C repro:   https://ci.syzbot.org/findings/f2e1c927-88dd-48df-af44-6348bc760ced/c_repro
syz repro: https://ci.syzbot.org/findings/f2e1c927-88dd-48df-af44-6348bc760ced/syz_repro

EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
ext4 filesystem being mounted at /0/file0 supports timestamps until 2038-01-19 (0x7fffffff)
==================================================================
BUG: KASAN: use-after-free in ext4_xattr_set_entry+0x179e/0x1e20 fs/ext4/xattr.c:1740
Read of size 260 at addr ffff88811cde4000 by task syz.0.17/5956

CPU: 0 UID: 0 PID: 5956 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 check_region_inline mm/kasan/generic.c:-1 [inline]
 kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200
 __asan_memmove+0x29/0x70 mm/kasan/shadow.c:94
 ext4_xattr_set_entry+0x179e/0x1e20 fs/ext4/xattr.c:1740
 ext4_xattr_block_set+0x636/0x2b00 fs/ext4/xattr.c:1961
 ext4_xattr_set_handle+0xdc2/0x14d0 fs/ext4/xattr.c:2432
 ext4_xattr_set+0x255/0x340 fs/ext4/xattr.c:2560
 __vfs_removexattr+0x431/0x470 fs/xattr.c:518
 __vfs_removexattr_locked+0xe2/0x280 fs/xattr.c:553
 vfs_removexattr+0x7f/0x230 fs/xattr.c:575
 ovl_do_removexattr fs/overlayfs/overlayfs.h:335 [inline]
 ovl_removexattr fs/overlayfs/overlayfs.h:343 [inline]
 ovl_make_workdir fs/overlayfs/super.c:760 [inline]
 ovl_get_workdir fs/overlayfs/super.c:840 [inline]
 ovl_fill_super_creds fs/overlayfs/super.c:1453 [inline]
 ovl_fill_super+0x4c09/0x5e00 fs/overlayfs/super.c:1564
 vfs_get_super fs/super.c:1327 [inline]
 get_tree_nodev+0xbb/0x150 fs/super.c:1346
 vfs_get_tree+0x92/0x2a0 fs/super.c:1754
 fc_mount fs/namespace.c:1193 [inline]
 do_new_mount_fc fs/namespace.c:3763 [inline]
 do_new_mount+0x341/0xd30 fs/namespace.c:3839
 do_mount fs/namespace.c:4172 [inline]
 __do_sys_mount fs/namespace.c:4361 [inline]
 __se_sys_mount+0x31d/0x420 fs/namespace.c:4338
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f60b0d9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcaa4270a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f60b1015fa0 RCX: 00007f60b0d9c799
RDX: 0000200000000b80 RSI: 0000200000000000 RDI: 0000000000000000
RBP: 00007f60b0e32bd9 R08: 0000200000000100 R09: 0000000000000000
R10: 0000000000000804 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f60b1015fac R14: 00007f60b1015fa0 R15: 00007f60b1015fa0
 </TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x39c pfn:0x11cde4
flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff)
raw: 017ff00000000000 ffffea0004737948 ffff888121040d70 0000000000000000
raw: 000000000000039c 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Movable, gfp_mask 0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), pid 5919, tgid 5919 (syz-executor), ts 71335198059, free_ts 71626869117
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2484
 folio_alloc_mpol_noprof mm/mempolicy.c:2503 [inline]
 vma_alloc_folio_noprof+0xea/0x210 mm/mempolicy.c:2538
 folio_prealloc mm/memory.c:-1 [inline]
 do_cow_fault mm/memory.c:5822 [inline]
 do_fault mm/memory.c:5934 [inline]
 do_pte_missing+0x4ea/0x3750 mm/memory.c:4477
 handle_pte_fault mm/memory.c:6316 [inline]
 __handle_mm_fault mm/memory.c:6454 [inline]
 handle_mm_fault+0x1bec/0x3310 mm/memory.c:6623
 do_user_addr_fault+0xa73/0x1340 arch/x86/mm/fault.c:1334
 handle_page_fault arch/x86/mm/fault.c:1474 [inline]
 exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
page last free pid 5920 tgid 5920 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 free_unref_folios+0xed5/0x16d0 mm/page_alloc.c:3040
 folios_put_refs+0x789/0x8d0 mm/swap.c:1002
 free_pages_and_swap_cache+0x537/0x5b0 mm/swap_state.c:426
 __tlb_batch_free_encoded_pages mm/mmu_gather.c:138 [inline]
 tlb_batch_pages_flush mm/mmu_gather.c:151 [inline]
 tlb_flush_mmu_free mm/mmu_gather.c:398 [inline]
 tlb_flush_mmu+0x6d3/0xa30 mm/mmu_gather.c:405
 tlb_finish_mmu+0xf9/0x230 mm/mmu_gather.c:530
 exit_mmap+0x498/0xa10 mm/mmap.c:1315
 __mmput+0x118/0x430 kernel/fork.c:1174
 exit_mm+0x168/0x220 kernel/exit.c:581
 do_exit+0x62e/0x2320 kernel/exit.c:959
 do_group_exit+0x21b/0x2d0 kernel/exit.c:1112
 get_signal+0x1284/0x1330 kernel/signal.c:3034
 arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
 __exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
 exit_to_user_mode_loop+0x86/0x480 kernel/entry/common.c:98
 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
 syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
 do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff88811cde3f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88811cde3f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88811cde4000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff88811cde4080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88811cde4100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[Edward Adam Davis]

#syz test

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ae3804f36535..5e00f39c09e1 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2193,8 +2193,11 @@ ext4_ext_insert_extent(handle_t *handle, struct inode *inode,
 		goto errout;
 
 	err = ext4_ext_dirty(handle, inode, path + path->p_depth);
-	if (err)
+	if (err) {
+		if (err == -EFSCORRUPTED && !ext4_has_feature_huge_file(inode->i_sb))
+			ext4_ext_remove_space(inode, newext->ee_block, newext->ee_block);
 		goto errout;
+	}
 
 	return path;
 

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com

Tested on:

commit:         c107785c Merge tag 'modules-7.0-rc3.fixes' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10298a02580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2a019678b1a3a692
dashboard link: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=17201552580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[Edward Adam Davis]

#syz test

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ae3804f36535..0bed3379f2d2 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4458,19 +4458,13 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
 	if (IS_ERR(path)) {
 		err = PTR_ERR(path);
 		if (allocated_clusters) {
-			int fb_flags = 0;
-
 			/*
 			 * free data blocks we just allocated.
 			 * not a good idea to call discard here directly,
 			 * but otherwise we'd need to call it every free().
 			 */
 			ext4_discard_preallocations(inode);
-			if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE)
-				fb_flags = EXT4_FREE_BLOCKS_NO_QUOT_UPDATE;
-			ext4_free_blocks(handle, inode, NULL, newblock,
-					 EXT4_C2B(sbi, allocated_clusters),
-					 fb_flags);
+			ext4_ext_remove_space(inode, newex.ee_block, newex.ee_block);
 		}
 		goto out;
 	}

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com

Tested on:

commit:         c107785c Merge tag 'modules-7.0-rc3.fixes' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12a81552580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2a019678b1a3a692
dashboard link: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1654b5aa580000

Note: testing is done by a robot and is best-effort only.

[PATCH v3] ext4: avoid infinite loops caused by residual data

[Edward Adam Davis]

On the mkdir/mknod path, when mapping logical blocks to physical blocks,
if inserting a new extent into the extent tree fails (in this example,
because the file system disabled the huge file feature when marking the
inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to
reclaim the physical block without deleting the corresponding data in
the extent tree. This causes subsequent mkdir operations to reference
the previously reclaimed physical block number again, even though this
physical block is already being used by the xattr block. Therefore, a
situation arises where both the directory and xattr are using the same
buffer head block in memory simultaneously.

The above causes ext4_xattr_block_set() to enter an infinite loop about
"inserted" and cannot release the inode lock, ultimately leading to the
143s blocking problem mentioned in [1].

By using ext4_ext_remove_space() to delete the inserted logical block
and reclaim the physical block when inserting a new extent fails during
extent block mapping, residual extent data can be prevented from affecting
subsequent logical block physical mappings. 

[1]
INFO: task syz.0.17:5995 blocked for more than 143 seconds.
Call Trace:
 inode_lock_nested include/linux/fs.h:1073 [inline]
 __start_dirop fs/namei.c:2923 [inline]
 start_dirop fs/namei.c:2934 [inline]

Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: fix ci reported issues
v2 -> v3: new fix for removing residual data and update subject and coments

 fs/ext4/extents.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ae3804f36535..0bed3379f2d2 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4458,19 +4458,13 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
 	if (IS_ERR(path)) {
 		err = PTR_ERR(path);
 		if (allocated_clusters) {
-			int fb_flags = 0;
-
 			/*
 			 * free data blocks we just allocated.
 			 * not a good idea to call discard here directly,
 			 * but otherwise we'd need to call it every free().
 			 */
 			ext4_discard_preallocations(inode);
-			if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE)
-				fb_flags = EXT4_FREE_BLOCKS_NO_QUOT_UPDATE;
-			ext4_free_blocks(handle, inode, NULL, newblock,
-					 EXT4_C2B(sbi, allocated_clusters),
-					 fb_flags);
+			ext4_ext_remove_space(inode, newex.ee_block, newex.ee_block);
 		}
 		goto out;
 	}
-- 
2.43.0

Re: [PATCH v3] ext4: avoid infinite loops caused by residual data

[Jan Kara]

On Thu 05-03-26 15:25:46, Edward Adam Davis wrote:
> On the mkdir/mknod path, when mapping logical blocks to physical blocks,
> if inserting a new extent into the extent tree fails (in this example,
> because the file system disabled the huge file feature when marking the
> inode as dirty),

I don't quite understand what you mean here but I think you say that
ext4_ext_dirty() -> ext4_mark_inode_dirty() returns error due to whatever
corruption it has hit.

> ext4_ext_map_blocks() only calls ext4_free_blocks() to
> reclaim the physical block without deleting the corresponding data in
> the extent tree. This causes subsequent mkdir operations to reference
> the previously reclaimed physical block number again, even though this
> physical block is already being used by the xattr block. Therefore, a
> situation arises where both the directory and xattr are using the same
> buffer head block in memory simultaneously.

OK, this indeed looks like "not so great" error handling. Thanks for
digging into this.

> The above causes ext4_xattr_block_set() to enter an infinite loop about
> "inserted" and cannot release the inode lock, ultimately leading to the
> 143s blocking problem mentioned in [1].
> 
> By using ext4_ext_remove_space() to delete the inserted logical block
> and reclaim the physical block when inserting a new extent fails during
> extent block mapping, residual extent data can be prevented from affecting
> subsequent logical block physical mappings. 
> 
> [1]
> INFO: task syz.0.17:5995 blocked for more than 143 seconds.
> Call Trace:
>  inode_lock_nested include/linux/fs.h:1073 [inline]
>  __start_dirop fs/namei.c:2923 [inline]
>  start_dirop fs/namei.c:2934 [inline]
> 
> Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
> Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
> Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
...
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index ae3804f36535..0bed3379f2d2 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -4458,19 +4458,13 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
>  	if (IS_ERR(path)) {
>  		err = PTR_ERR(path);
>  		if (allocated_clusters) {
> -			int fb_flags = 0;
> -
>  			/*
>  			 * free data blocks we just allocated.
>  			 * not a good idea to call discard here directly,
>  			 * but otherwise we'd need to call it every free().
>  			 */
>  			ext4_discard_preallocations(inode);
> -			if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE)
> -				fb_flags = EXT4_FREE_BLOCKS_NO_QUOT_UPDATE;
> -			ext4_free_blocks(handle, inode, NULL, newblock,
> -					 EXT4_C2B(sbi, allocated_clusters),
> -					 fb_flags);
> +			ext4_ext_remove_space(inode, newex.ee_block, newex.ee_block);

So I'm concerned that if the metadata is corrupted, then trying to remove
some extent space can do even more harm. Also in case
EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, we now wrongly update quota
information. So this definitely isn't a correct fix. What I'd do instead
would be distinguishing two cases:

1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully
consistent and we must maintain its consistency including all the
accounting. However these errors can happen only early before we've
inserted the extent into the extent tree. So current code works correctly
for this case.

2) Some other error - this means metadata is corrupted. We should strive to
do as few modifications as possible to limit damage. So I'd just skip
freeing of allocated blocks.

Long story short I think we should just modify the above condition:

	if (allocated_clusters)

to

	/*
	 * Gracefully handle out of space conditions. If the filesystem is
	 * inconsistent, we'll just leak allocated blocks to avoid causing
	 * even more damage.
	 */
	if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC))

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH v3] ext4: avoid infinite loops caused by residual data

[Edward Adam Davis]

On Thu, 5 Mar 2026 11:38:00 +0100 Jan Kara wrote:
> > On the mkdir/mknod path, when mapping logical blocks to physical blocks,
> > if inserting a new extent into the extent tree fails (in this example,
> > because the file system disabled the huge file feature when marking the
> > inode as dirty),
> 
> I don't quite understand what you mean here but I think you say that
> ext4_ext_dirty() -> ext4_mark_inode_dirty() returns error due to whatever
> corruption it has hit.
It returns -EFSCORRUPTED in following calltrace: 
ext4_ext_dirty()->
  ext4_mark_inode_dirty()->
    __ext4_mark_inode_dirty()->
      ext4_mark_iloc_dirty()->
        ext4_do_update_inode()->
	  ext4_fill_raw_inode()->
	    ext4_inode_blocks_set()->
	      if (!ext4_has_feature_huge_file(sb))
	          return -EFSCORRUPTED;
> 
> > ext4_ext_map_blocks() only calls ext4_free_blocks() to
> > reclaim the physical block without deleting the corresponding data in
> > the extent tree. This causes subsequent mkdir operations to reference
> > the previously reclaimed physical block number again, even though this
> > physical block is already being used by the xattr block. Therefore, a
> > situation arises where both the directory and xattr are using the same
> > buffer head block in memory simultaneously.
> 
> OK, this indeed looks like "not so great" error handling. Thanks for
> digging into this.
> 
> > The above causes ext4_xattr_block_set() to enter an infinite loop about
> > "inserted" and cannot release the inode lock, ultimately leading to the
> > 143s blocking problem mentioned in [1].
> >
> > By using ext4_ext_remove_space() to delete the inserted logical block
> > and reclaim the physical block when inserting a new extent fails during
> > extent block mapping, residual extent data can be prevented from affecting
> > subsequent logical block physical mappings.
> >
> > [1]
> > INFO: task syz.0.17:5995 blocked for more than 143 seconds.
> > Call Trace:
> >  inode_lock_nested include/linux/fs.h:1073 [inline]
> >  __start_dirop fs/namei.c:2923 [inline]
> >  start_dirop fs/namei.c:2934 [inline]
> >
> > Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
> > Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> > Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
> > Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> ...
> > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> > index ae3804f36535..0bed3379f2d2 100644
> > --- a/fs/ext4/extents.c
> > +++ b/fs/ext4/extents.c
> > @@ -4458,19 +4458,13 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
> >  	if (IS_ERR(path)) {
> >  		err = PTR_ERR(path);
> >  		if (allocated_clusters) {
> > -			int fb_flags = 0;
> > -
> >  			/*
> >  			 * free data blocks we just allocated.
> >  			 * not a good idea to call discard here directly,
> >  			 * but otherwise we'd need to call it every free().
> >  			 */
> >  			ext4_discard_preallocations(inode);
> > -			if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE)
> > -				fb_flags = EXT4_FREE_BLOCKS_NO_QUOT_UPDATE;
> > -			ext4_free_blocks(handle, inode, NULL, newblock,
> > -					 EXT4_C2B(sbi, allocated_clusters),
> > -					 fb_flags);
> > +			ext4_ext_remove_space(inode, newex.ee_block, newex.ee_block);
> 
> So I'm concerned that if the metadata is corrupted, then trying to remove
> some extent space can do even more harm. Also in case
> EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, we now wrongly update quota
> information. So this definitely isn't a correct fix. What I'd do instead
> would be distinguishing two cases:
> 
> 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully
> consistent and we must maintain its consistency including all the
> accounting. However these errors can happen only early before we've
> inserted the extent into the extent tree. So current code works correctly
> for this case.
> 
> 2) Some other error - this means metadata is corrupted. We should strive to
> do as few modifications as possible to limit damage. So I'd just skip
> freeing of allocated blocks.
> 
> Long story short I think we should just modify the above condition:
> 
> 	if (allocated_clusters)
> 
> to
> 
> 	/*
> 	 * Gracefully handle out of space conditions. If the filesystem is
> 	 * inconsistent, we'll just leak allocated blocks to avoid causing
> 	 * even more damage.
> 	 */
> 	if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC))
I have tested the modified code, and now it no longer deletes any data
for the -EFSCORRUPTED error (before applying my patch, it only deleted
the physical block and not the corresponding data in the extent tree).
This also prevents conflicts caused by data being reused by dir and
xattr.

I will release a new patch later to add the filtering you requested.

BR,
Edward

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[Edward Adam Davis]

#syz test

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ae3804f36535..56b7398a0b40 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4457,20 +4457,19 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
 	path = ext4_ext_insert_extent(handle, inode, path, &newex, flags);
 	if (IS_ERR(path)) {
 		err = PTR_ERR(path);
-		if (allocated_clusters) {
-			int fb_flags = 0;
-
+		/*
+		 * Gracefully handle out of space conditions. If the filesystem
+		 * is inconsistent, we'll just leak allocated blocks to avoid
+		 * causing even more damage.
+		 */
+		if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC)) {
 			/*
 			 * free data blocks we just allocated.
 			 * not a good idea to call discard here directly,
 			 * but otherwise we'd need to call it every free().
 			 */
 			ext4_discard_preallocations(inode);
-			if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE)
-				fb_flags = EXT4_FREE_BLOCKS_NO_QUOT_UPDATE;
-			ext4_free_blocks(handle, inode, NULL, newblock,
-					 EXT4_C2B(sbi, allocated_clusters),
-					 fb_flags);
+			ext4_ext_remove_space(inode, newex.ee_block, newex.ee_block);
 		}
 		goto out;
 	}

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com

Tested on:

commit:         c107785c Merge tag 'modules-7.0-rc3.fixes' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11938a02580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2a019678b1a3a692
dashboard link: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=14a37006580000

Note: testing is done by a robot and is best-effort only.

[PATCH v4] ext4: avoid infinite loops caused by residual data

[Edward Adam Davis]

On the mkdir/mknod path, when mapping logical blocks to physical blocks,
if inserting a new extent into the extent tree fails (in this example,
because the file system disabled the huge file feature when marking the
inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to
reclaim the physical block without deleting the corresponding data in
the extent tree. This causes subsequent mkdir operations to reference
the previously reclaimed physical block number again, even though this
physical block is already being used by the xattr block. Therefore, a
situation arises where both the directory and xattr are using the same
buffer head block in memory simultaneously.

The above causes ext4_xattr_block_set() to enter an infinite loop about
"inserted" and cannot release the inode lock, ultimately leading to the
143s blocking problem mentioned in [1].

By using ext4_ext_remove_space() to delete the inserted logical block
and reclaim the physical block when inserting a new extent fails during
extent block mapping, either delete both as described above, or retain
the data completely (i.e., neither delete the physical block nor the
data in the extent tree), residual extent data can be prevented from
affecting subsequent logical block physical mappings. 

Besides the errors ENOSPC or EDQUOT, this means metadata is corrupted.
We should strive to do as few modifications as possible to limit damage.
So just skip freeing of allocated blocks.

[1]
INFO: task syz.0.17:5995 blocked for more than 143 seconds.
Call Trace:
 inode_lock_nested include/linux/fs.h:1073 [inline]
 __start_dirop fs/namei.c:2923 [inline]
 start_dirop fs/namei.c:2934 [inline]

Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: fix ci reported issues
v2 -> v3: new fix for removing residual data and update subject and coments
v3 -> v4: filtering already allocated blocks and update comments

 fs/ext4/extents.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ae3804f36535..56b7398a0b40 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4457,20 +4457,19 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
 	path = ext4_ext_insert_extent(handle, inode, path, &newex, flags);
 	if (IS_ERR(path)) {
 		err = PTR_ERR(path);
-		if (allocated_clusters) {
-			int fb_flags = 0;
-
+		/*
+		 * Gracefully handle out of space conditions. If the filesystem
+		 * is inconsistent, we'll just leak allocated blocks to avoid
+		 * causing even more damage.
+		 */
+		if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC)) {
 			/*
 			 * free data blocks we just allocated.
 			 * not a good idea to call discard here directly,
 			 * but otherwise we'd need to call it every free().
 			 */
 			ext4_discard_preallocations(inode);
-			if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE)
-				fb_flags = EXT4_FREE_BLOCKS_NO_QUOT_UPDATE;
-			ext4_free_blocks(handle, inode, NULL, newblock,
-					 EXT4_C2B(sbi, allocated_clusters),
-					 fb_flags);
+			ext4_ext_remove_space(inode, newex.ee_block, newex.ee_block);
 		}
 		goto out;
 	}
-- 
2.43.0

Re: [PATCH v4] ext4: avoid infinite loops caused by residual data

[Jan Kara]

On Thu 05-03-26 22:12:03, Edward Adam Davis wrote:
> On the mkdir/mknod path, when mapping logical blocks to physical blocks,
> if inserting a new extent into the extent tree fails (in this example,
> because the file system disabled the huge file feature when marking the
> inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to
> reclaim the physical block without deleting the corresponding data in
> the extent tree. This causes subsequent mkdir operations to reference
> the previously reclaimed physical block number again, even though this
> physical block is already being used by the xattr block. Therefore, a
> situation arises where both the directory and xattr are using the same
> buffer head block in memory simultaneously.
> 
> The above causes ext4_xattr_block_set() to enter an infinite loop about
> "inserted" and cannot release the inode lock, ultimately leading to the
> 143s blocking problem mentioned in [1].
> 
> By using ext4_ext_remove_space() to delete the inserted logical block
> and reclaim the physical block when inserting a new extent fails during
> extent block mapping, either delete both as described above, or retain
> the data completely (i.e., neither delete the physical block nor the
> data in the extent tree), residual extent data can be prevented from
> affecting subsequent logical block physical mappings. 
> 
> Besides the errors ENOSPC or EDQUOT, this means metadata is corrupted.
> We should strive to do as few modifications as possible to limit damage.
> So just skip freeing of allocated blocks.
> 
> [1]
> INFO: task syz.0.17:5995 blocked for more than 143 seconds.
> Call Trace:
>  inode_lock_nested include/linux/fs.h:1073 [inline]
>  __start_dirop fs/namei.c:2923 [inline]
>  start_dirop fs/namei.c:2934 [inline]
> 
> Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
> Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
> Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>

...

> @@ -4457,20 +4457,19 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
>  	path = ext4_ext_insert_extent(handle, inode, path, &newex, flags);
>  	if (IS_ERR(path)) {
>  		err = PTR_ERR(path);
> -		if (allocated_clusters) {
> -			int fb_flags = 0;
> -
> +		/*
> +		 * Gracefully handle out of space conditions. If the filesystem
> +		 * is inconsistent, we'll just leak allocated blocks to avoid
> +		 * causing even more damage.
> +		 */
> +		if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC)) {

This is fine now...

>  			/*
>  			 * free data blocks we just allocated.
>  			 * not a good idea to call discard here directly,
>  			 * but otherwise we'd need to call it every free().
>  			 */
>  			ext4_discard_preallocations(inode);
> -			if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE)
> -				fb_flags = EXT4_FREE_BLOCKS_NO_QUOT_UPDATE;
> -			ext4_free_blocks(handle, inode, NULL, newblock,
> -					 EXT4_C2B(sbi, allocated_clusters),
> -					 fb_flags);
> +			ext4_ext_remove_space(inode, newex.ee_block, newex.ee_block);

But this won't work because in case of errors like ENOSPC there's no extent
inserted into the tree so ext4_ext_remove_space() won't do anything. Just
don't touch the freeing code and things will be fine...

								Honza

>  		}
>  		goto out;
>  	}
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[Edward Adam Davis]

#syz test

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ae3804f36535..4779da94f816 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4457,9 +4457,13 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
 	path = ext4_ext_insert_extent(handle, inode, path, &newex, flags);
 	if (IS_ERR(path)) {
 		err = PTR_ERR(path);
-		if (allocated_clusters) {
+		/*
+		 * Gracefully handle out of space conditions. If the filesystem
+		 * is inconsistent, we'll just leak allocated blocks to avoid
+		 * causing even more damage.
+		 */
+		if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC)) {
 			int fb_flags = 0;
-
 			/*
 			 * free data blocks we just allocated.
 			 * not a good idea to call discard here directly,

[PATCH v5] ext4: avoid infinite loops caused by residual data

[Edward Adam Davis]

On the mkdir/mknod path, when mapping logical blocks to physical blocks,
if inserting a new extent into the extent tree fails (in this example,
because the file system disabled the huge file feature when marking the
inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to
reclaim the physical block without deleting the corresponding data in
the extent tree. This causes subsequent mkdir operations to reference
the previously reclaimed physical block number again, even though this
physical block is already being used by the xattr block. Therefore, a
situation arises where both the directory and xattr are using the same
buffer head block in memory simultaneously.

The above causes ext4_xattr_block_set() to enter an infinite loop about
"inserted" and cannot release the inode lock, ultimately leading to the
143s blocking problem mentioned in [1].

If the metadata is corrupted, then trying to remove some extent space
can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE
was passed, remove space wrongly update quota information.
Jan Kara suggests distinguishing between two cases:

1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully
consistent and we must maintain its consistency including all the
accounting. However these errors can happen only early before we've
inserted the extent into the extent tree. So current code works correctly
for this case.

2) Some other error - this means metadata is corrupted. We should strive to
do as few modifications as possible to limit damage. So I'd just skip
freeing of allocated blocks.

[1]
INFO: task syz.0.17:5995 blocked for more than 143 seconds.
Call Trace:
 inode_lock_nested include/linux/fs.h:1073 [inline]
 __start_dirop fs/namei.c:2923 [inline]
 start_dirop fs/namei.c:2934 [inline]

Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: fix ci reported issues
v2 -> v3: new fix for removing residual data and update subject and coments
v3 -> v4: filtering already allocated blocks and update comments
v4 -> v5: don't touch corrupted data and update comments

 fs/ext4/extents.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ae3804f36535..4779da94f816 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4457,9 +4457,13 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
 	path = ext4_ext_insert_extent(handle, inode, path, &newex, flags);
 	if (IS_ERR(path)) {
 		err = PTR_ERR(path);
-		if (allocated_clusters) {
+		/*
+		 * Gracefully handle out of space conditions. If the filesystem
+		 * is inconsistent, we'll just leak allocated blocks to avoid
+		 * causing even more damage.
+		 */
+		if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC)) {
 			int fb_flags = 0;
-
 			/*
 			 * free data blocks we just allocated.
 			 * not a good idea to call discard here directly,
-- 
2.43.0

Re: [syzbot] [ext4?] INFO: task hung in filename_unlinkat

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com

Tested on:

commit:         5ee8dbf5 Merge tag 'fsverity-for-linus' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14b0fb5a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2a019678b1a3a692
dashboard link: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=17a0fb5a580000

Note: testing is done by a robot and is best-effort only.

Re: [PATCH v5] ext4: avoid infinite loops caused by residual data

[Jan Kara]

On Fri 06-03-26 09:31:58, Edward Adam Davis wrote:
> On the mkdir/mknod path, when mapping logical blocks to physical blocks,
> if inserting a new extent into the extent tree fails (in this example,
> because the file system disabled the huge file feature when marking the
> inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to
> reclaim the physical block without deleting the corresponding data in
> the extent tree. This causes subsequent mkdir operations to reference
> the previously reclaimed physical block number again, even though this
> physical block is already being used by the xattr block. Therefore, a
> situation arises where both the directory and xattr are using the same
> buffer head block in memory simultaneously.
> 
> The above causes ext4_xattr_block_set() to enter an infinite loop about
> "inserted" and cannot release the inode lock, ultimately leading to the
> 143s blocking problem mentioned in [1].
> 
> If the metadata is corrupted, then trying to remove some extent space
> can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE
> was passed, remove space wrongly update quota information.
> Jan Kara suggests distinguishing between two cases:
> 
> 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully
> consistent and we must maintain its consistency including all the
> accounting. However these errors can happen only early before we've
> inserted the extent into the extent tree. So current code works correctly
> for this case.
> 
> 2) Some other error - this means metadata is corrupted. We should strive to
> do as few modifications as possible to limit damage. So I'd just skip
> freeing of allocated blocks.
> 
> [1]
> INFO: task syz.0.17:5995 blocked for more than 143 seconds.
> Call Trace:
>  inode_lock_nested include/linux/fs.h:1073 [inline]
>  __start_dirop fs/namei.c:2923 [inline]
>  start_dirop fs/namei.c:2934 [inline]
> 
> Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7
> Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f
> Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>

Looks good to me! Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza


> ---
> v1 -> v2: fix ci reported issues
> v2 -> v3: new fix for removing residual data and update subject and coments
> v3 -> v4: filtering already allocated blocks and update comments
> v4 -> v5: don't touch corrupted data and update comments
> 
>  fs/ext4/extents.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index ae3804f36535..4779da94f816 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -4457,9 +4457,13 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
>  	path = ext4_ext_insert_extent(handle, inode, path, &newex, flags);
>  	if (IS_ERR(path)) {
>  		err = PTR_ERR(path);
> -		if (allocated_clusters) {
> +		/*
> +		 * Gracefully handle out of space conditions. If the filesystem
> +		 * is inconsistent, we'll just leak allocated blocks to avoid
> +		 * causing even more damage.
> +		 */
> +		if (allocated_clusters && (err == -EDQUOT || err == -ENOSPC)) {
>  			int fb_flags = 0;
> -
>  			/*
>  			 * free data blocks we just allocated.
>  			 * not a good idea to call discard here directly,
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH v5] ext4: avoid infinite loops caused by residual data

[Theodore Ts'o]

On Fri, 06 Mar 2026 09:31:58 +0800, Edward Adam Davis wrote:
> On the mkdir/mknod path, when mapping logical blocks to physical blocks,
> if inserting a new extent into the extent tree fails (in this example,
> because the file system disabled the huge file feature when marking the
> inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to
> reclaim the physical block without deleting the corresponding data in
> the extent tree. This causes subsequent mkdir operations to reference
> the previously reclaimed physical block number again, even though this
> physical block is already being used by the xattr block. Therefore, a
> situation arises where both the directory and xattr are using the same
> buffer head block in memory simultaneously.
> 
> [...]

Applied, thanks!

[1/1] ext4: avoid infinite loops caused by residual data
      commit: 86709d389530941e5816505e3c12c757ceca374d

Best regards,
-- 
Theodore Ts'o <tytso@mit.edu>