[syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    72d3fcf802c4 Linux 7.3-rc5
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=147f6325580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=718e346eb0b8f38
dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12379605580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=127f6325580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6e221bb16a33/disk-72d3fcf8.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/705025f5cae2/vmlinux-72d3fcf8.xz
kernel image: https://storage.googleapis.com/syzbot-assets/5f22341c14fa/bzImage-72d3fcf8.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/5d87cd1c0001/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=17e37605580000)

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

==================================================================
BUG: KASAN: slab-use-after-free in dx_move_dirents fs/ext4/namei.c:1863 [inline]
BUG: KASAN: slab-use-after-free in do_split+0x1241/0x1e90 fs/ext4/namei.c:1993
Write of size 90458 at addr ffff88803b38ac6e by task syz.0.17/6003

CPU: 1 UID: 0 PID: 6003 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/16/2026
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 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_memset+0x22/0x50 mm/kasan/shadow.c:84
 dx_move_dirents fs/ext4/namei.c:1863 [inline]
 do_split+0x1241/0x1e90 fs/ext4/namei.c:1993
 make_indexed_dir+0xdab/0x1360 fs/ext4/namei.c:2328
 __ext4_add_entry+0x1e77/0x1ff0 fs/ext4/namei.c:2432
 ext4_add_entry fs/ext4/namei.c:2469 [inline]
 ext4_rename fs/ext4/namei.c:3939 [inline]
 ext4_rename2+0x1f71/0x3270 fs/ext4/namei.c:4218
 vfs_rename+0xbd9/0xef0 fs/namei.c:6208
 filename_renameat2+0x533/0x9b0 fs/namei.c:6326
 __do_sys_rename fs/namei.c:6370 [inline]
 __se_sys_rename+0x55/0x2c0 fs/namei.c:6366
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe7da7be159
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:00007fe7d9dfd028 EFLAGS: 00000246 ORIG_RAX: 0000000000000052
RAX: ffffffffffffffda RBX: 00007fe7daa46090 RCX: 00007fe7da7be159
RDX: 0000000000000000 RSI: 0000200000000780 RDI: 0000200000000100
RBP: 00007fe7da85506b R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe7daa46128 R14: 00007fe7daa46090 R15: 00007fff45d807e8
 </TASK>

The buggy address belongs to the physical page:
page: refcount:2 mapcount:0 mapping:ffff888023717420 index:0x8 pfn:0x3b38a
memcg:ffff88801c2dc200
aops:def_blk_aops ino:700000 dentry name(?):""
flags: 0x8000000000493c(referenced|uptodate|dirty|lru|active|owner_2|private|node=0|zone=1)
raw: 008000000000493c ffffea0000efb748 ffffea0000d68388 ffff888023717420
raw: 0000000000000008 ffff8880235dbb40 00000002ffffffff ffff88801c2dc200
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 5836, tgid 5836 (udevd), ts 120465350871
 set_page_owner include/linux/page_owner.h:33 [inline]
 post_alloc_hook+0x1f9/0x250 mm/page_alloc.c:1871
 prep_new_page mm/page_alloc.c:1879 [inline]
 get_page_from_freelist+0x2591/0x2600 mm/page_alloc.c:3943
 __alloc_frozen_pages_noprof+0x230/0x5c0 mm/page_alloc.c:5436
 alloc_pages_mpol+0xd4/0x280 mm/mempolicy.c:2486
 alloc_frozen_pages_noprof mm/mempolicy.c:2557 [inline]
 alloc_pages_noprof+0xd2/0x2f0 mm/mempolicy.c:2577
 folio_alloc_noprof+0x22/0xc0 mm/mempolicy.c:2587
 filemap_alloc_folio_noprof+0x111/0x4c0 mm/filemap.c:1019
 ractl_alloc_folio mm/readahead.c:200 [inline]
 page_cache_ra_unbounded+0x2d6/0x8f0 mm/readahead.c:288
 do_page_cache_ra mm/readahead.c:348 [inline]
 force_page_cache_ra+0x26f/0x2e0 mm/readahead.c:378
 filemap_get_pages+0x493/0x1e80 mm/filemap.c:2714
 filemap_read+0x429/0x11e0 mm/filemap.c:2824
 blkdev_read_iter+0x2f8/0x430 block/fops.c:832
 new_sync_read fs/read_write.c:493 [inline]
 vfs_read+0x59e/0xa90 fs/read_write.c:574
 ksys_read+0x156/0x270 fs/read_write.c:716
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 28 tgid 28 ts 120462276719 stack trace:
 reset_page_owner include/linux/page_owner.h:26 [inline]
 __free_pages_prepare mm/page_alloc.c:1418 [inline]
 __free_frozen_pages+0xf8e/0x1070 mm/page_alloc.c:2962
 __tlb_remove_table_free mm/mmu_gather.c:228 [inline]
 tlb_remove_table_rcu+0x85/0x100 mm/mmu_gather.c:291
 rcu_do_batch kernel/rcu/tree.c:2650 [inline]
 rcu_core kernel/rcu/tree.c:2919 [inline]
 rcu_cpu_kthread+0xb2c/0x1740 kernel/rcu/tree.c:3007
 smpboot_thread_fn+0x565/0xa70 kernel/smpboot.c:160
 kthread+0x38b/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 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:
 ffff88803b38af00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88803b38af80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88803b38b000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                   ^
 ffff88803b38b080: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fa fb
 ffff88803b38b100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


---
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?] KASAN: slab-use-after-free Write in do_split

[syzbot]

syzbot has bisected this issue to:

commit 3f757b56f1c4579fe32b810bce1d39f202964412
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri May 16 16:07:40 2025 +0000

    btrfs: unfold transaction aborts at btrfs_create_new_inode()

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16bbf315580000
start commit:   72d3fcf802c4 Linux 7.3-rc5
git tree:       upstream
final oops:     https://syzkaller.appspot.com/x/report.txt?x=15bbf315580000
console output: https://syzkaller.appspot.com/x/log.txt?x=11bbf315580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=718e346eb0b8f38
dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12379605580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=127f6325580000

Reported-by: syzbot+09bec78ee77613a3efdd@syzkaller.appspotmail.com
Fixes: 3f757b56f1c4 ("btrfs: unfold transaction aborts at btrfs_create_new_inode()")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[Qu Wenruo]

在 2026/9/29 10:02, syzbot 写道:
> syzbot has bisected this issue to:
> 
> commit 3f757b56f1c4579fe32b810bce1d39f202964412
> Author: Filipe Manana <fdmanana@suse.com>
> Date:   Fri May 16 16:07:40 2025 +0000
> 
>      btrfs: unfold transaction aborts at btrfs_create_new_inode()

This bisection doesn't make any sense.

The console output is showing ext4_add_entry()->do_split() causing the 
KASAN.

Furthermore, there is no btrfs in the whole console output.

There must be some randomness in the reproducer.

> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16bbf315580000
> start commit:   72d3fcf802c4 Linux 7.3-rc5
> git tree:       upstream
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=15bbf315580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=11bbf315580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=718e346eb0b8f38
> dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12379605580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=127f6325580000
> 
> Reported-by: syzbot+09bec78ee77613a3efdd@syzkaller.appspotmail.com
> Fixes: 3f757b56f1c4 ("btrfs: unfold transaction aborts at btrfs_create_new_inode()")
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Forwarded: [PATCH] ext4: validate dirents before splitting a directory

[syzbot]

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

***

Subject: [PATCH] ext4: validate dirents before splitting a directory
Author: adrianox@gmail.com

#syz test: upstream master
syzbot reported a slab-use-after-free write in do_split() while
renaming an entry in a directory that is being converted into an
indexed (htree) directory by make_indexed_dir():

  BUG: KASAN: slab-use-after-free in dx_move_dirents [inline]
  BUG: KASAN: slab-use-after-free in do_split+0x1241/0x1e90
  Write of size 90458 at addr ffff88803b38ac6e by task syz.0.17/6003

do_split() builds a map of the leaf's dirents and then moves a subset
of them to a new block.  dx_move_dirents() trusts map[i].offs and uses
the rec_len found there as the length of a memset().  With a corrupted
or crafted directory block, a bogus map entry makes that rec_len
garbage (here 90464), turning the memset() into an out-of-bounds write
that can corrupt arbitrary memory.

Validate each entry that is about to be moved with
ext4_check_dir_entry() before using it, and bail out with
-EFSCORRUPTED if the entry does not lie inside the block.  This is the
same class of validation already used elsewhere in the directory code.

This is a filesystem-corruption hardening issue; the crash needs a
corrupt directory, which is why it is not reachable on a consistent
filesystem.  The syzbot "introduced by" bisection pointed at an
unrelated btrfs commit and can be ignored.

Closes: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
---
 fs/ext4/namei.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index a6386c1d237f..b2ec222b15e4 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1951,6 +1951,25 @@ static struct ext4_dir_entry_2 *do_split(handle_t *handle, struct inode *dir,
 		goto journal_error;
 	}
 	map -= count;
+	/*
+	 * The map is built from the on-disk dirents, so its entries should
+	 * always refer to valid dirents.  However, if the leaf block is
+	 * corrupted (e.g. a crafted image), a bogus map entry can make
+	 * dx_move_dirents() read a rec_len from an arbitrary location and use
+	 * it as the length of a memset(), writing far out of bounds.  Validate
+	 * every entry we are about to move before using it.
+	 */
+	for (i = 0; i < count; i++) {
+		unsigned int off = map[i].offs << 2;
+
+		if (off > blocksize - sizeof(struct ext4_dir_entry_2) ||
+		    ext4_check_dir_entry(dir, NULL,
+					 (struct ext4_dir_entry_2 *)(data1 + off),
+					 *bh, data1, blocksize, off)) {
+			err = -EFSCORRUPTED;
+			goto out;
+		}
+	}
 	dx_sort_map(map, count);
 	/* Ensure that neither split block is over half full */
 	size = 0;
-- 
2.51.0

Forwarded: [PATCH] ext4: don't trust on-disk rec_len in dx_move_dirents()

[syzbot]

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

***

Subject: [PATCH] ext4: don't trust on-disk rec_len in dx_move_dirents()
Author: adrianox@gmail.com

#syz test: upstream master
---
 fs/ext4/namei.c | 38 ++++++++++++++++++++++++++++++--------
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index a6386c1d237f..83e4564f9f44 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1840,30 +1840,46 @@ struct dentry *ext4_get_parent(struct dentry *child)
 
 /*
  * Move count entries from end of map between two memory locations.
- * Returns pointer to last entry moved.
+ * Returns pointer to last entry moved or an ERR_PTR on a corrupt entry.
  */
 static struct ext4_dir_entry_2 *
 dx_move_dirents(struct inode *dir, char *from, char *to,
 		struct dx_map_entry *map, int count,
 		unsigned blocksize)
 {
+	char *to_start = to;
 	unsigned rec_len = 0;
 
 	while (count--) {
-		struct ext4_dir_entry_2 *de = (struct ext4_dir_entry_2 *)
-						(from + (map->offs<<2));
+		unsigned int off = map->offs << 2;
+		struct ext4_dir_entry_2 *de;
+
+		/*
+		 * The map is built from on-disk dirents, but a corrupted or
+		 * concurrently reused leaf block can still make an entry point
+		 * outside the block.  Never dereference such an entry.
+		 */
+		if (off > blocksize - sizeof(struct ext4_dir_entry_2))
+			return ERR_PTR(-EFSCORRUPTED);
+		de = (struct ext4_dir_entry_2 *)(from + off);
 		rec_len = ext4_dir_rec_len(de->name_len, dir);
+		if (off + rec_len > blocksize ||
+		    to + rec_len > to_start + blocksize)
+			return ERR_PTR(-EFSCORRUPTED);
 
 		memcpy (to, de, rec_len);
 		((struct ext4_dir_entry_2 *) to)->rec_len =
 				ext4_rec_len_to_disk(rec_len, blocksize);
 
-		/* wipe dir_entry excluding the rec_len field */
+		/*
+		 * Wipe dir_entry excluding the rec_len field.  Use the entry's
+		 * own (minimal) length instead of the untrusted on-disk rec_len,
+		 * which on a corrupt block decodes to an arbitrary huge value
+		 * and turns this into an out-of-bounds memset().
+		 */
 		de->inode = 0;
-		memset(&de->name_len, 0, ext4_rec_len_from_disk(de->rec_len,
-								blocksize) -
-					 offsetof(struct ext4_dir_entry_2,
-								name_len));
+		memset(&de->name_len, 0, rec_len -
+		       offsetof(struct ext4_dir_entry_2, name_len));
 
 		map++;
 		to += rec_len;
@@ -1992,6 +2008,12 @@ static struct ext4_dir_entry_2 *do_split(handle_t *handle, struct inode *dir,
 	/* Fancy dance to stay within two buffers */
 	de2 = dx_move_dirents(dir, data1, data2, map + split, count - split,
 			      blocksize);
+	if (IS_ERR(de2)) {
+		ext4_error_inode_block(dir, (*bh)->b_blocknr, 0,
+				       "bad indexed directory entry");
+		err = PTR_ERR(de2);
+		goto out;
+	}
 	de = dx_pack_dirents(dir, data1, blocksize);
 	de->rec_len = ext4_rec_len_to_disk(data1 + (blocksize - csum_size) -
 					   (char *) de,
-- 
2.51.0

Forwarded: [PATCH] ext4: don't trust on-disk rec_len in dx_move_dirents()

[syzbot]

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

***

Subject: [PATCH] ext4: don't trust on-disk rec_len in dx_move_dirents()
Author: adrianox@gmail.com

#syz test: upstream master
syzbot reported an out-of-bounds write from do_split() while a directory
is converted to an indexed one:

  BUG: KASAN: slab-out-of-bounds in dx_move_dirents [inline]
  BUG: KASAN: slab-out-of-bounds in do_split+0xf9c/0x1de0
  Write of size 90458

dx_move_dirents() wipes the source entry using its on-disk rec_len.
That field can't be trusted: on a corrupt block it may be garbage
(0x6161 here) and ext4_rec_len_from_disk() turns it into a huge value,
so the memset() runs far past the block.  The entry is already copied
using its own real length, so use that length for the wipe as well.

Closes: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
---
 fs/ext4/namei.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index a6386c1d237f..71e9e7c9a7fd 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1860,10 +1860,8 @@ dx_move_dirents(struct inode *dir, char *from, char *to,
 
 		/* wipe dir_entry excluding the rec_len field */
 		de->inode = 0;
-		memset(&de->name_len, 0, ext4_rec_len_from_disk(de->rec_len,
-								blocksize) -
-					 offsetof(struct ext4_dir_entry_2,
-								name_len));
+		memset(&de->name_len, 0, rec_len -
+		       offsetof(struct ext4_dir_entry_2, name_len));
 
 		map++;
 		to += rec_len;
-- 
2.51.0

Forwarded: [PATCH] ext4: don't append a directory block already mapped in the inode

[syzbot]

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

***

Subject: [PATCH] ext4: don't append a directory block already mapped in the inode
Author: adrianox@gmail.com

#syz test: upstream master
---
 fs/ext4/namei.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 3b9740c1c16d..7b356baf7bd4 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -83,6 +83,36 @@ static struct buffer_head *ext4_append(handle_t *handle,
 	bh = ext4_bread(handle, inode, *block, EXT4_GET_BLOCKS_CREATE);
 	if (IS_ERR(bh))
 		return bh;
+
+	/*
+	 * The logical block was a hole, but a corrupt block bitmap can make
+	 * the allocator hand out a physical block that is already in use,
+	 * possibly by another block of this very inode.  Callers such as
+	 * do_split()/make_indexed_dir() assume the newly appended block is
+	 * distinct from the blocks they are about to modify; if it aliases
+	 * one of them, moving directory entries between the two buffers
+	 * corrupts the directory.  Make sure the new block is not already
+	 * mapped by this inode.
+	 */
+	for (map.m_lblk = 0; map.m_lblk < *block; ) {
+		map.m_len = *block - map.m_lblk;
+		err = ext4_map_blocks(NULL, inode, &map, 0);
+		if (err < 0)
+			goto out;
+		if (err == 0) {
+			map.m_lblk++;
+			continue;
+		}
+		if (unlikely(map.m_pblk == bh->b_blocknr)) {
+			EXT4_ERROR_INODE(inode,
+					 "new block %llu already mapped",
+					 (unsigned long long)bh->b_blocknr);
+			err = -EFSCORRUPTED;
+			goto out;
+		}
+		map.m_lblk += map.m_len;
+	}
+
 	inode->i_size += inode->i_sb->s_blocksize;
 	EXT4_I(inode)->i_disksize = inode->i_size;
 	err = ext4_mark_inode_dirty(handle, inode);
-- 
2.51.0

Forwarded: [PATCH] ext4: don't append a directory block already mapped in the inode

[syzbot]

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

***

Subject: [PATCH] ext4: don't append a directory block already mapped in the inode
Author: adrianox@gmail.com

#syz test: upstream 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e
---
 fs/ext4/namei.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 3b9740c1c16d..ff6013306b74 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -83,6 +83,25 @@ static struct buffer_head *ext4_append(handle_t *handle,
 	bh = ext4_bread(handle, inode, *block, EXT4_GET_BLOCKS_CREATE);
 	if (IS_ERR(bh))
 		return bh;
+
+	for (map.m_lblk = 0; map.m_lblk < *block; map.m_lblk += map.m_len) {
+		map.m_len = *block - map.m_lblk;
+		err = ext4_map_blocks(NULL, inode, &map, 0);
+		if (err < 0)
+			goto out;
+		if (err == 0) {
+			map.m_len = 1;
+			continue;
+		}
+		if (unlikely(map.m_pblk == bh->b_blocknr)) {
+			EXT4_ERROR_INODE(inode,
+					 "new block %llu already mapped",
+					 (unsigned long long)bh->b_blocknr);
+			err = -EFSCORRUPTED;
+			goto out;
+		}
+	}
+
 	inode->i_size += inode->i_sb->s_blocksize;
 	EXT4_I(inode)->i_disksize = inode->i_size;
 	err = ext4_mark_inode_dirty(handle, inode);
-- 
2.51.0

Forwarded: [PATCH] ext4: don't append a directory block already mapped in the inode

[syzbot]

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

***

Subject: [PATCH] ext4: don't append a directory block already mapped in the inode
Author: adrianox@gmail.com

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e
ext4_append() grows a directory by one block.  It checks that the target
logical block is a hole, but a corrupt block bitmap can still make the
allocator hand back a physical block that is already in use by this
inode.  The in-memory copy of a block is keyed by its physical block
number, so the "new" block and that existing one are the same memory;
callers that split a directory (make_indexed_dir()/do_split()) then move
entries between two aliased buffers and corrupt the directory, until a
bogus rec_len read from the middle of a name runs the wipe out of bounds:

  BUG: KASAN: slab-use-after-free in dx_move_dirents [inline]
  Write of size 90458 ...

Reject the block and report the corrupt bitmap instead of corrupting
memory.

Closes: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
---
 fs/ext4/namei.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 3b9740c1c16d..7a0dadf6c5fe 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -83,6 +83,25 @@ static struct buffer_head *ext4_append(handle_t *handle,
 	bh = ext4_bread(handle, inode, *block, EXT4_GET_BLOCKS_CREATE);
 	if (IS_ERR(bh))
 		return bh;
+
+	for (map.m_lblk = 0; map.m_lblk < *block; map.m_lblk += map.m_len) {
+		map.m_len = *block - map.m_lblk;
+		err = ext4_map_blocks(NULL, inode, &map, 0);
+		if (err < 0) {
+			brelse(bh);
+			return ERR_PTR(err);
+		}
+		if (err > 0 && bh->b_blocknr - map.m_pblk < map.m_len) {
+			EXT4_ERROR_INODE(inode,
+					 "new block %llu already mapped",
+					 (unsigned long long)bh->b_blocknr);
+			brelse(bh);
+			return ERR_PTR(-EFSCORRUPTED);
+		}
+		if (map.m_len < 1)
+			map.m_len = 1;
+	}
+
 	inode->i_size += inode->i_sb->s_blocksize;
 	EXT4_I(inode)->i_disksize = inode->i_size;
 	err = ext4_mark_inode_dirty(handle, inode);
-- 
2.51.0

Re: [syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: slab-out-of-bounds Write in do_split

==================================================================
BUG: KASAN: slab-out-of-bounds in dx_move_dirents fs/ext4/namei.c:1863 [inline]
BUG: KASAN: slab-out-of-bounds in do_split+0xf9c/0x1de0 fs/ext4/namei.c:2012
Write of size 90458 at addr ffff888032276c6e by task syz.0.77/6895
Write of size 90458 at addr ffff888032276c6e by task syz.0.77/6895

CPU: 1 UID: 0 PID: 6895 Comm: syz.0.77 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/16/2026
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 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_memset+0x22/0x50 mm/kasan/shadow.c:84
 dx_move_dirents fs/ext4/namei.c:1863 [inline]
 do_split+0xf9c/0x1de0 fs/ext4/namei.c:2012
 make_indexed_dir+0xdab/0x1360 fs/ext4/namei.c:2347
 __ext4_add_entry+0x1e77/0x1ff0 fs/ext4/namei.c:2451
 ext4_add_entry fs/ext4/namei.c:2488 [inline]
 ext4_rename fs/ext4/namei.c:3958 [inline]
 ext4_rename2+0x1f71/0x3270 fs/ext4/namei.c:4237
 vfs_rename+0xbd9/0xef0 fs/namei.c:6208
 filename_renameat2+0x533/0x9b0 fs/namei.c:6326
 __do_sys_rename fs/namei.c:6370 [inline]
 __se_sys_rename+0x55/0x2c0 fs/namei.c:6366
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb2e4cce159
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:00007fb2e430d028 EFLAGS: 00000246 ORIG_RAX: 0000000000000052
RAX: ffffffffffffffda RBX: 00007fb2e4f56090 RCX: 00007fb2e4cce159
RDX: 0000000000000000 RSI: 0000200000000780 RDI: 0000200000000100
RBP: 00007fb2e4d6506b R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb2e4f56128 R14: 00007fb2e4f56090 R15: 00007ffd63540a48
 </TASK>

The buggy address belongs to the physical page:
page: refcount:2 mapcount:0 mapping:ffff8880235f7420 index:0x8 pfn:0x32276
memcg:ffff88801c2dc200
aops:def_blk_aops ino:700000 dentry name(?):""
flags: 0x8000000000493c(referenced|uptodate|dirty|lru|active|owner_2|private|node=0|zone=1)
raw: 008000000000493c ffffea0000c5ca88 ffff88801aed5ff8 ffff8880235f7420
raw: 0000000000000008 ffff88804e147240 00000002ffffffff ffff88801c2dc200
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 6830, tgid 6830 (udevd), ts 205206771286
 set_page_owner include/linux/page_owner.h:33 [inline]
 post_alloc_hook+0x1f9/0x250 mm/page_alloc.c:1871
 prep_new_page mm/page_alloc.c:1879 [inline]
 get_page_from_freelist+0x2591/0x2600 mm/page_alloc.c:3943
 __alloc_frozen_pages_noprof+0x230/0x5c0 mm/page_alloc.c:5436
 alloc_pages_mpol+0xd4/0x280 mm/mempolicy.c:2486
 alloc_frozen_pages_noprof mm/mempolicy.c:2557 [inline]
 alloc_pages_noprof+0xd2/0x2f0 mm/mempolicy.c:2577
 folio_alloc_noprof+0x22/0xc0 mm/mempolicy.c:2587
 filemap_alloc_folio_noprof+0x111/0x4c0 mm/filemap.c:1019
 ractl_alloc_folio mm/readahead.c:200 [inline]
 page_cache_ra_unbounded+0x2d6/0x8f0 mm/readahead.c:288
 do_page_cache_ra mm/readahead.c:348 [inline]
 force_page_cache_ra+0x26f/0x2e0 mm/readahead.c:378
 filemap_get_pages+0x493/0x1e80 mm/filemap.c:2714
 filemap_read+0x429/0x11e0 mm/filemap.c:2824
 blkdev_read_iter+0x2f8/0x430 block/fops.c:832
 new_sync_read fs/read_write.c:493 [inline]
 vfs_read+0x59e/0xa90 fs/read_write.c:574
 ksys_read+0x156/0x270 fs/read_write.c:716
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 20 tgid 20 ts 205159236283 stack trace:
 reset_page_owner include/linux/page_owner.h:26 [inline]
 __free_pages_prepare mm/page_alloc.c:1418 [inline]
 __free_frozen_pages+0xf8e/0x1070 mm/page_alloc.c:2962
 __tlb_remove_table_free mm/mmu_gather.c:228 [inline]
 tlb_remove_table_rcu+0x85/0x100 mm/mmu_gather.c:291
 rcu_do_batch kernel/rcu/tree.c:2650 [inline]
 rcu_core kernel/rcu/tree.c:2919 [inline]
 rcu_cpu_kthread+0xb2c/0x1740 kernel/rcu/tree.c:3007
 smpboot_thread_fn+0x565/0xa70 kernel/smpboot.c:160
 kthread+0x38b/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 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:
 ffff888032276f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888032276f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888032277000: 00 00 fc fc 00 04 fc fc fa fb fc fc 00 05 fc fc
                         ^
 ffff888032277080: fa fb fc fc fa fb fc fc 00 00 fc fc 00 00 fc fc
 ffff888032277100: fa fb fc fc fa fb fc fc 00 00 fc fc fa fb fc fc
==================================================================


Tested on:

commit:         d24e8ac7 Merge tag 'net-7.3-rc6' of git://git.kernel.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1269c725580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=718e346eb0b8f38
dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=12dec725580000

Re: [syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[syzbot]

Hello,

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

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

Tested on:

commit:         d24e8ac7 Merge tag 'net-7.3-rc6' of git://git.kernel.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=165673f5580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=718e346eb0b8f38
dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=113953f5580000

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

Re: [syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[syzbot]

Hello,

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

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

Tested on:

commit:         d24e8ac7 Merge tag 'net-7.3-rc6' of git://git.kernel.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17862035580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=718e346eb0b8f38
dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10b756c9580000

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

Re: [syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[syzbot]

Hello,

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

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

Tested on:

commit:         7704c4c5 Merge tag 'i2c-fixes-7.3-rc6' of git://git.ke..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=178897f5580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=341a98f91c13ec9
dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=14fc27f5580000

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

Re: [syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[syzbot]

Hello,

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

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

Tested on:

commit:         72d3fcf8 Linux 7.3-rc5
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=11c0a835580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=718e346eb0b8f38
dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=16b527f5580000

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

Re: [syzbot] [ext4?] KASAN: slab-use-after-free Write in do_split

[syzbot]

Hello,

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

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

Tested on:

commit:         72d3fcf8 Linux 7.3-rc5
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1472dec9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=718e346eb0b8f38
dashboard link: https://syzkaller.appspot.com/bug?extid=09bec78ee77613a3efdd
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=15ccdec9580000

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