[syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

[syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    2961f841b025 Merge tag 'turbostat-2026.02.14' of git://git..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=156cb15a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=665cbf0979cda6c5
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
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=17a43b3a580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=157f895a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/54d6a30cbc5f/disk-2961f841.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/40003e4ec76c/vmlinux-2961f841.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2db393aba9ff/bzImage-2961f841.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/07bdbcf04dc1/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=12b95c02580000)

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

loop0: detected capacity change from 1024 to 64
EXT4-fs error (device loop0): ext4_find_dest_de:2050: inode #12: block 7: comm syz.0.17: bad entry in directory: directory entry overrun - offset=0, inode=268435456, rec_len=1280, size=56 fake=0
==================================================================
BUG: KASAN: use-after-free in xattr_find_entry+0x1a5/0x280 fs/ext4/xattr.c:334
Read of size 4 at addr ffff88806ee29004 by task syz.0.17/5997

CPU: 1 UID: 49663 PID: 5997 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(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
 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
 xattr_find_entry+0x1a5/0x280 fs/ext4/xattr.c:334
 ext4_xattr_ibody_get+0x232/0x4c0 fs/ext4/xattr.c:655
 ext4_xattr_get+0x123/0x6a0 fs/ext4/xattr.c:709
 ext4_get_acl+0x84/0x930 fs/ext4/acl.c:165
 __get_acl+0x27e/0x410 fs/posix_acl.c:159
 check_acl+0x3a/0x150 fs/namei.c:385
 acl_permission_check fs/namei.c:471 [inline]
 generic_permission+0x497/0x690 fs/namei.c:524
 do_inode_permission fs/namei.c:585 [inline]
 inode_permission+0x243/0x5f0 fs/namei.c:648
 lookup_inode_permission_may_exec fs/namei.c:-1 [inline]
 may_lookup fs/namei.c:1973 [inline]
 link_path_walk+0x1149/0x18d0 fs/namei.c:2595
 path_lookupat+0xe4/0x8c0 fs/namei.c:2803
 filename_lookup+0x256/0x5d0 fs/namei.c:2833
 user_path_at+0x40/0x160 fs/namei.c:3612
 do_mount fs/namespace.c:4156 [inline]
 __do_sys_mount fs/namespace.c:4348 [inline]
 __se_sys_mount+0x2dc/0x420 fs/namespace.c:4325
 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:0x7f72cdd9c629
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:00007fff6aba2c28 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f72ce015fa0 RCX: 00007f72cdd9c629
RDX: 0000000000000000 RSI: 0000200000000040 RDI: 0000000000000000
RBP: 00007f72cde32b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000002094080 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f72ce015fac R14: 00007f72ce015fa0 R15: 00007f72ce015fa0
 </TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x7f3283789 pfn:0x6ee29
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea0001bb8a88 ffffea0001bb8908 0000000000000000
raw: 00000007f3283789 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 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO|__GFP_COMP), pid 5981, tgid 5981 (sed), ts 108386366383, free_ts 108399318838
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1888
 prep_new_page mm/page_alloc.c:1896 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3961
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5249
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2485
 folio_alloc_mpol_noprof mm/mempolicy.c:2504 [inline]
 vma_alloc_folio_noprof+0xea/0x210 mm/mempolicy.c:2539
 folio_prealloc mm/memory.c:-1 [inline]
 alloc_anon_folio mm/memory.c:5200 [inline]
 do_anonymous_page mm/memory.c:5257 [inline]
 do_pte_missing+0x1656/0x3750 mm/memory.c:4467
 handle_pte_fault mm/memory.c:6308 [inline]
 __handle_mm_fault mm/memory.c:6446 [inline]
 handle_mm_fault+0x1bec/0x3310 mm/memory.c:6615
 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 5981 tgid 5981 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1432 [inline]
 free_unref_folios+0xd38/0x14c0 mm/page_alloc.c:3039
 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+0x453/0xdb0 mm/mmap.c:1290
 __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:
 ffff88806ee28f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88806ee28f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88806ee29000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff88806ee29080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88806ee29100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


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

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

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

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

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

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

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

Forwarded: [PATCH] ext4: add bounds check in xattr_find_entry() to prevent use-after-free

[syzbot]

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

***

Subject: [PATCH] ext4: add bounds check in xattr_find_entry() to prevent use-after-free
Author: kartikey406@gmail.com

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


xattr_find_entry() receives an 'end' pointer to mark the boundary of
the valid xattr region, but never uses it to validate entries during
iteration. The IS_LAST_ENTRY() check dereferences the entry pointer
(reading 4 bytes) without first verifying that the entry is within
bounds. On a corrupted filesystem, this allows the loop to walk past
the valid buffer into freed memory, triggering a use-after-free.

This is observed when mounting a crafted ext4 image where inline xattr
entries in the inode body are corrupted. During path lookup, the ACL
permission check calls ext4_get_acl() -> ext4_xattr_ibody_get() ->
xattr_find_entry(), which iterates over the corrupted inline xattr
entries and reads from a freed page.

Fix this by adding a bounds check against 'end' before each entry
is accessed in the iteration loop, and validating that the next entry
also falls within bounds. Return -EFSCORRUPTED if the xattr entries
overrun the valid region.

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

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..5080ec44228a 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -652,6 +652,13 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
 	header = IHDR(inode, raw_inode);
 	end = ITAIL(inode, raw_inode);
 	entry = IFIRST(header);
+
+	if ((void *)entry + sizeof(__u32) > end) {
+		EXT4_ERROR_INODE(inode, "inline xattr region overflow");
+		error = -EFSCORRUPTED;
+		goto cleanup;
+	}
+
 	error = xattr_find_entry(inode, &entry, end, name_index, name, 0);
 	if (error)
 		goto cleanup;
-- 
2.34.1

Forwarded: [PATCH] ext4: add bounds check in xattr_find_entry() to prevent use-after-free

[syzbot]

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

***

Subject: [PATCH] ext4: add bounds check in xattr_find_entry() to prevent use-after-free
Author: kartikey406@gmail.com

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



xattr_find_entry() receives an 'end' pointer to mark the boundary of
the valid xattr region but never uses it to validate entries during
iteration. The IS_LAST_ENTRY() macro dereferences the entry pointer
by casting it to __u32 and reading 4 bytes, without first verifying
that the entry falls within bounds.

On a corrupted filesystem, inline xattr entries in the inode body can
have a bogus e_name_len field. EXT4_XATTR_NEXT() uses e_name_len to
compute the next entry offset, which can jump past the valid xattr
region into freed memory. The subsequent IS_LAST_ENTRY() call on this
out-of-bounds pointer triggers a use-after-free read.

Fix this by:
1. Checking that the entry pointer is within bounds before each
   IS_LAST_ENTRY() dereference in the loop condition.
2. Validating that the next entry computed via EXT4_XATTR_NEXT()
   also falls within bounds before advancing the loop.

Return -EFSCORRUPTED if entries overrun the valid xattr region.

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

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..f38eef93e3f8 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -333,6 +333,12 @@ xattr_find_entry(struct inode *inode, struct ext4_xattr_entry **pentry,
 	name_len = strlen(name);
 	for (entry = *pentry; !IS_LAST_ENTRY(entry); entry = next) {
 		next = EXT4_XATTR_NEXT(entry);
+		if ((void *)next + sizeof(__u32) > end) {
+			EXT4_ERROR_INODE(inode, "corrupted xattr entry: e_name_len=%u",
+			                  entry->e_name_len);
+			return -EFSCORRUPTED;
+		}
+
 		if ((void *) next >= end) {
 			EXT4_ERROR_INODE(inode, "corrupted xattr entries");
 			return -EFSCORRUPTED;
@@ -652,6 +658,13 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
 	header = IHDR(inode, raw_inode);
 	end = ITAIL(inode, raw_inode);
 	entry = IFIRST(header);
+
+	if ((void *)entry + sizeof(__u32) > end) {
+		EXT4_ERROR_INODE(inode, "inline xattr region overflow");
+		error = -EFSCORRUPTED;
+		goto cleanup;
+	}
+
 	error = xattr_find_entry(inode, &entry, end, name_index, name, 0);
 	if (error)
 		goto cleanup;
-- 
2.34.1

Forwarded: [PATCH] ext4: fix bounds check in check_xattrs() to account for IS_LAST_ENTRY() read

[syzbot]

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

***

Subject: [PATCH] ext4: fix bounds check in check_xattrs() to account for IS_LAST_ENTRY() read
Author: kartikey406@gmail.com

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


The bounds check for the next xattr entry in check_xattrs() uses
(void *)next >= end, which allows next to point within sizeof(u32)
bytes of end. On the next iteration, IS_LAST_ENTRY() reads 4 bytes
from next via *(__u32 *)(entry), which can overrun the valid xattr
region and access freed memory.

This is triggered when mounting a corrupted ext4 filesystem where the
inode's i_extra_isize leaves insufficient space for inline xattr
entries. The ACL permission check calls ext4_get_acl() ->
ext4_xattr_ibody_get() -> xattr_find_entry(), which reads past the
inode buffer.

Fix this by changing the check to (void *)next + sizeof(u32) > end,
ensuring there is always enough space for the IS_LAST_ENTRY() read
on the subsequent iteration.

Reported-by: syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
Link: https://lore.kernel.org/all/20260224231429.31361-1-kartikey406@gmail.com/T/ [v1]
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>

---
v2: Move the fix to check_xattrs() as suggested by Ted Ts'o, instead
    of adding a separate check in ext4_xattr_ibody_get().
---
 fs/ext4/xattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..c6205b405efe 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -226,7 +226,7 @@ check_xattrs(struct inode *inode, struct buffer_head *bh,
 	/* Find the end of the names list */
 	while (!IS_LAST_ENTRY(e)) {
 		struct ext4_xattr_entry *next = EXT4_XATTR_NEXT(e);
-		if ((void *)next >= end) {
+		if ((void *)next + sizeof(u32) > end) {
 			err_str = "e_name out of bounds";
 			goto errout;
 		}
-- 
2.43.0

Forwarded: [PATCH] ext4: add debug printk to trace xattr validation path

[syzbot]

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

***

Subject: [PATCH] ext4: add debug printk to trace xattr validation path
Author: kartikey406@gmail.com

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


Add temporary printk statements to trace the inline xattr validation
code path for debugging syzbot use-after-free in xattr_find_entry().

This helps determine whether __xattr_check_inode() is being called
before ext4_xattr_ibody_get() accesses inline xattr entries, and
what the IFIRST/ITAIL gap values are at each stage.

Not for upstream submission - debug only.

Reported-by: syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/inode.c | 4 ++++
 fs/ext4/xattr.c | 8 ++++++++
 2 files changed, 12 insertions(+)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 396dc3a5d16b..af3a6992bf20 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5331,11 +5331,15 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
 
 	if (EXT4_INODE_SIZE(inode->i_sb) > EXT4_GOOD_OLD_INODE_SIZE) {
 		if (ei->i_extra_isize == 0) {
+			 printk("DEBUG: inode %lu: i_extra_isize == 0, skipping xattr check\n",
+               inode->i_ino);
 			/* The extra space is currently unused. Use it. */
 			BUILD_BUG_ON(sizeof(struct ext4_inode) & 3);
 			ei->i_extra_isize = sizeof(struct ext4_inode) -
 					    EXT4_GOOD_OLD_INODE_SIZE;
 		} else {
+			 printk("DEBUG: inode %lu: calling ext4_iget_extra_inode\n",
+               inode->i_ino);
 			ret = ext4_iget_extra_inode(inode, raw_inode, ei);
 			if (ret)
 				goto bad_inode;
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..abc27521a3a8 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -316,6 +316,9 @@ int
 __xattr_check_inode(struct inode *inode, struct ext4_xattr_ibody_header *header,
 			 void *end, const char *function, unsigned int line)
 {
+	printk("DEBUG: inode %lu: __xattr_check_inode called, IFIRST=%px end=%px gap=%ld\n",
+           inode->i_ino, IFIRST(header), end,
+           (long)(end - (void *)IFIRST(header)));
 	return check_xattrs(inode, NULL, IFIRST(header), end, IFIRST(header),
 			    function, line);
 }
@@ -645,6 +648,8 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
 
 	if (!ext4_test_inode_state(inode, EXT4_STATE_XATTR))
 		return -ENODATA;
+	printk("DEBUG: inode %lu: ext4_xattr_ibody_get called, EXT4_STATE_XATTR is set\n",
+       inode->i_ino);
 	error = ext4_get_inode_loc(inode, &iloc);
 	if (error)
 		return error;
@@ -652,6 +657,9 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
 	header = IHDR(inode, raw_inode);
 	end = ITAIL(inode, raw_inode);
 	entry = IFIRST(header);
+	printk("DEBUG: inode %lu: ibody_get IFIRST=%px end=%px gap=%ld\n",
+		inode->i_ino, entry, end,
+		(long)(end - (void *)entry));
 	error = xattr_find_entry(inode, &entry, end, name_index, name, 0);
 	if (error)
 		goto cleanup;
-- 
2.43.0

Forwarded: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device

[syzbot]

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

***

Subject: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device
Author: kartikey406@gmail.com

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

LOOP_SET_STATUS{64} allows changing lo_offset and lo_sizelimit while
a filesystem is mounted on the loop device. This effectively mutates
the data visible to the mounted filesystem, which is equivalent to
writing directly to the block device.

When bdev_allow_write_mounted is false, direct writes to a mounted
block device are blocked via bdev_writes_blocked(). However,
LOOP_SET_STATUS{64} bypasses this protection because it modifies
the loop configuration through an ioctl rather than opening the
block device for writing.

Fix this by checking bdev_writes_blocked() before allowing changes
to lo_offset or lo_sizelimit. If the loop device has writes blocked
(indicating a filesystem is mounted with write protection), return
-EBUSY. Other loop status fields that do not affect the visible
data can still be changed while mounted.

Export bdev_writes_blocked() so it can be used from the loop driver.

Suggested-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 block/bdev.c           |  4 +++-
 drivers/block/loop.c   | 12 ++++++++++++
 include/linux/blkdev.h |  1 +
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/block/bdev.c b/block/bdev.c
index ed022f8c48c7..96520fac7b2f 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -860,10 +860,12 @@ void blkdev_put_no_open(struct block_device *bdev)
 	put_device(&bdev->bd_device);
 }
 
-static bool bdev_writes_blocked(struct block_device *bdev)
+bool bdev_writes_blocked(struct block_device *bdev)
 {
 	return bdev->bd_writers < 0;
 }
+EXPORT_SYMBOL_GPL(bdev_writes_blocked);
+
 
 static void bdev_block_writes(struct block_device *bdev)
 {
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0000913f7efc..3f3a29abad1f 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1239,6 +1239,18 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
 		goto out_unlock;
 	}
 
+	/*
+	 * Changing lo_offset or lo_sizelimit on a mounted device is
+	 * equivalent to modifying the block device contents, block
+	 * this if writes are blocked on the device.
+	 */
+	if ((lo->lo_offset != info->lo_offset ||
+	     lo->lo_sizelimit != info->lo_sizelimit) &&
+	    bdev_writes_blocked(lo->lo_device)) {
+		err = -EBUSY;
+		goto out_unlock;
+	}
+
 	if (lo->lo_offset != info->lo_offset ||
 	    lo->lo_sizelimit != info->lo_sizelimit) {
 		size_changed = true;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d463b9b5a0a5..6b908e9dd035 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -820,6 +820,7 @@ static inline bool bdev_read_only(struct block_device *bdev)
 	return bdev_test_flag(bdev, BD_READ_ONLY) || get_disk_ro(bdev->bd_disk);
 }
 
+bool bdev_writes_blocked(struct block_device *bdev);
 bool set_capacity_and_notify(struct gendisk *disk, sector_t size);
 void disk_force_media_change(struct gendisk *disk);
 void bdev_mark_dead(struct block_device *bdev, bool surprise);
-- 
2.43.0

Forwarded: [PATCH] loop: block changing lo_offset/lo_sizelimit on mounted device

[syzbot]

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

***

Subject: [PATCH] loop: block changing lo_offset/lo_sizelimit on mounted device
Author: kartikey406@gmail.com

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

LOOP_SET_STATUS{64} allows changing lo_offset and shrinking
lo_sizelimit while a filesystem is mounted on the loop device.
This effectively mutates the data visible to the mounted filesystem,
which is equivalent to writing directly to the block device.

When CONFIG_BLK_DEV_WRITE_MOUNTED is disabled, direct writes to a
mounted block device are blocked. However, LOOP_SET_STATUS{64}
bypasses this protection because it modifies the loop configuration
through an ioctl rather than opening the block device for writing.

Fix this by checking bdev_writes_blocked() before allowing changes
to lo_offset or shrinking lo_sizelimit. If the loop device has
writes blocked, return -EBUSY. Increasing lo_sizelimit is still
allowed since growing the device is harmless and has legitimate
use cases such as online resize.

Move bdev_writes_blocked() from block/bdev.c to
include/linux/blk_types.h as a static inline function so it can
be used from the loop driver without exporting a symbol.

Reported-by: syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
v2:
  - Use #ifndef CONFIG_BLK_DEV_WRITE_MOUNTED instead of exporting
    bdev_writes_blocked(), as suggested by Ted Ts'o
  - Move bdev_writes_blocked() to include/linux/blk_types.h as
    static inline instead of exporting from block/bdev.c, as
    suggested by Christoph Hellwig
  - Allow increasing lo_sizelimit since growing the device is
    harmless, as pointed out by Christoph Hellwig
  - Remove spurious empty line
---
 block/bdev.c              |  5 -----
 drivers/block/loop.c      | 16 ++++++++++++++++
 include/linux/blk_types.h |  5 +++++
 3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/block/bdev.c b/block/bdev.c
index ed022f8c48c7..e0bace1a6c27 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -860,11 +860,6 @@ void blkdev_put_no_open(struct block_device *bdev)
 	put_device(&bdev->bd_device);
 }
 
-static bool bdev_writes_blocked(struct block_device *bdev)
-{
-	return bdev->bd_writers < 0;
-}
-
 static void bdev_block_writes(struct block_device *bdev)
 {
 	bdev->bd_writers--;
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0000913f7efc..34bbbf3bcb36 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1239,6 +1239,22 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
 		goto out_unlock;
 	}
 
+#ifndef CONFIG_BLK_DEV_WRITE_MOUNTED
+	/*
+	 * Changing lo_offset or shrinking lo_sizelimit on a mounted
+	 * device is equivalent to modifying the block device contents.
+	 * Block this if writes to the device are blocked.
+	 */
+	if ((lo->lo_offset != info->lo_offset ||
+	     (info->lo_sizelimit &&
+	      (lo->lo_sizelimit == 0 ||
+	       info->lo_sizelimit < lo->lo_sizelimit))) &&
+	    bdev_writes_blocked(lo->lo_device)) {
+		err = -EBUSY;
+		goto out_unlock;
+	}
+#endif
+
 	if (lo->lo_offset != info->lo_offset ||
 	    lo->lo_sizelimit != info->lo_sizelimit) {
 		size_changed = true;
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 8808ee76e73c..82ece8737b85 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -84,6 +84,11 @@ struct block_device {
 #define bdev_whole(_bdev) \
 	((_bdev)->bd_disk->part0)
 
+static inline bool bdev_writes_blocked(struct block_device *bdev)
+{
+	return bdev->bd_writers < 0;
+}
+
 #define dev_to_bdev(device) \
 	container_of((device), struct block_device, bd_device)
 
-- 
2.43.0

Re: [syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

[syzbot]

Hello,

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

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

Tested on:

commit:         7dff99b3 Remove WARN_ALL_UNSEEDED_RANDOM kernel config..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1699155a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=93740e6c6567fcec
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
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=15fe355a580000

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

Re: [syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

[syzbot]

Hello,

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

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

Tested on:

commit:         7dff99b3 Remove WARN_ALL_UNSEEDED_RANDOM kernel config..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14f1355a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=93740e6c6567fcec
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
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=1777b722580000

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

Re: [syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: use-after-free Read in xattr_find_entry

loop0: detected capacity change from 1024 to 64
==================================================================
BUG: KASAN: use-after-free in xattr_find_entry+0x1a5/0x280 fs/ext4/xattr.c:334
Read of size 4 at addr ffff88806233f004 by task syz.0.17/6393

CPU: 1 UID: 49663 PID: 6393 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(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
 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
 xattr_find_entry+0x1a5/0x280 fs/ext4/xattr.c:334
 ext4_xattr_ibody_get+0x232/0x4c0 fs/ext4/xattr.c:655
 ext4_xattr_get+0x123/0x6a0 fs/ext4/xattr.c:709
 ext4_get_acl+0x84/0x930 fs/ext4/acl.c:165
 __get_acl+0x27e/0x410 fs/posix_acl.c:159
 check_acl+0x3a/0x150 fs/namei.c:385
 acl_permission_check fs/namei.c:471 [inline]
 generic_permission+0x497/0x690 fs/namei.c:524
 do_inode_permission fs/namei.c:585 [inline]
 inode_permission+0x243/0x5f0 fs/namei.c:648
 lookup_inode_permission_may_exec fs/namei.c:-1 [inline]
 may_lookup fs/namei.c:1973 [inline]
 link_path_walk+0x1149/0x18d0 fs/namei.c:2595
 path_lookupat+0xe4/0x8c0 fs/namei.c:2803
 filename_lookup+0x256/0x5d0 fs/namei.c:2833
 user_path_at+0x40/0x160 fs/namei.c:3612
 do_mount fs/namespace.c:4169 [inline]
 __do_sys_mount fs/namespace.c:4361 [inline]
 __se_sys_mount+0x2dc/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:0x7f14f759c629
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:00007f14f845c028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f14f7815fa0 RCX: 00007f14f759c629
RDX: 0000000000000000 RSI: 0000200000000040 RDI: 0000000000000000
RBP: 00007f14f7632b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000002094080 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f14f7816038 R14: 00007f14f7815fa0 R15: 00007ffd4455cb58
 </TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x3c9 pfn:0x6233f
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea000188d008 ffffea0001cecd88 0000000000000000
raw: 00000000000003c9 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 6183, tgid 6183 (syz-executor), ts 130974047320, free_ts 131341169720
 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:5823 [inline]
 do_fault mm/memory.c:5935 [inline]
 do_pte_missing+0x4ea/0x3490 mm/memory.c:4477
 handle_pte_fault mm/memory.c:6317 [inline]
 __handle_mm_fault mm/memory.c:6455 [inline]
 handle_mm_fault+0x1bec/0x3310 mm/memory.c:6624
 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 6184 tgid 6184 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:1175
 exit_mm+0x168/0x220 kernel/exit.c:581
 do_exit+0x6a2/0x23c0 kernel/exit.c:964
 do_group_exit+0x21b/0x2d0 kernel/exit.c:1118
 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:
 ffff88806233ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88806233ef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88806233f000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff88806233f080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88806233f100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


Tested on:

commit:         0138af24 Merge tag 'erofs-for-7.0-rc6-fixes' of git://..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13bad06a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b643133b3e44c9fd
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
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=16da8eda580000

Re: [syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: use-after-free Read in xattr_find_entry

DEBUG: inode 12: ibody_get IFIRST=ffff88806edbcfa4 end=ffff88806edbd000 gap=92
EXT4-fs error (device loop0): ext4_find_dest_de:2050: inode #12: block 7: comm syz.0.17: bad entry in directory: directory entry overrun - offset=0, inode=268435456, rec_len=1280, size=56 fake=0
DEBUG: inode 12: ext4_xattr_ibody_get called, EXT4_STATE_XATTR is set
DEBUG: inode 12: ibody_get IFIRST=ffff88806edbd004 end=ffff88806edbd000 gap=-4
==================================================================
BUG: KASAN: use-after-free in xattr_find_entry+0x1a5/0x280 fs/ext4/xattr.c:337
Read of size 4 at addr ffff88806edbd004 by task syz.0.17/6418

CPU: 0 UID: 49663 PID: 6418 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(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
 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
 xattr_find_entry+0x1a5/0x280 fs/ext4/xattr.c:337
 ext4_xattr_ibody_get+0x314/0x560 fs/ext4/xattr.c:663
 ext4_xattr_get+0x123/0x6a0 fs/ext4/xattr.c:717
 ext4_get_acl+0x84/0x930 fs/ext4/acl.c:165
 __get_acl+0x27e/0x410 fs/posix_acl.c:159
 check_acl+0x3a/0x150 fs/namei.c:385
 acl_permission_check fs/namei.c:471 [inline]
 generic_permission+0x497/0x690 fs/namei.c:524
 do_inode_permission fs/namei.c:585 [inline]
 inode_permission+0x243/0x5f0 fs/namei.c:648
 lookup_inode_permission_may_exec fs/namei.c:-1 [inline]
 may_lookup fs/namei.c:1973 [inline]
 link_path_walk+0x1149/0x18d0 fs/namei.c:2595
 path_lookupat+0xe4/0x8c0 fs/namei.c:2803
 filename_lookup+0x256/0x5d0 fs/namei.c:2833
 user_path_at+0x40/0x160 fs/namei.c:3612
 do_mount fs/namespace.c:4169 [inline]
 __do_sys_mount fs/namespace.c:4361 [inline]
 __se_sys_mount+0x2dc/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:0x7fda1a19c629
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:00007fda1b0a4028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fda1a415fa0 RCX: 00007fda1a19c629
RDX: 0000000000000000 RSI: 0000200000000040 RDI: 0000000000000000
RBP: 00007fda1a232b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000002094080 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fda1a416038 R14: 00007fda1a415fa0 R15: 00007ffe64a91a68
 </TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x7f26dbd9c pfn:0x6edbd
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea0001bb6008 ffffea0001bb8dc8 0000000000000000
raw: 00000007f26dbd9c 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 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO|__GFP_COMP), pid 6414, tgid 6414 (rm), ts 151550332214, free_ts 151570996513
 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]
 alloc_anon_folio mm/memory.c:5209 [inline]
 do_anonymous_page mm/memory.c:5266 [inline]
 do_pte_missing+0x1656/0x3490 mm/memory.c:4475
 handle_pte_fault mm/memory.c:6317 [inline]
 __handle_mm_fault mm/memory.c:6455 [inline]
 handle_mm_fault+0x1bec/0x3310 mm/memory.c:6624
 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 6414 tgid 6414 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:1175
 exit_mm+0x168/0x220 kernel/exit.c:581
 do_exit+0x6a2/0x23c0 kernel/exit.c:964
 do_group_exit+0x21b/0x2d0 kernel/exit.c:1118
 __do_sys_exit_group kernel/exit.c:1129 [inline]
 __se_sys_exit_group kernel/exit.c:1127 [inline]
 __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1127
 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:
 ffff88806edbcf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88806edbcf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88806edbd000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff88806edbd080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88806edbd100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


Tested on:

commit:         46b51325 Merge tag 'v7.0-rc5-smb3-client-fix' of git:/..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=173a9848580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b643133b3e44c9fd
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
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=175a4eda580000

Re: [syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

[syzbot]

Hello,

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

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

Tested on:

commit:         7aaa8047 Linux 7.0-rc6
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11487cca580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b643133b3e44c9fd
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
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=1243ff52580000

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

Re: [syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

[syzbot]

Hello,

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

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

Tested on:

commit:         d0c3bcd5 Merge tag 'libcrypto-for-linus' of git://git...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=148c99ca580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b643133b3e44c9fd
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
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=132eb3d6580000

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