#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
syzbot reported multiple use-after-free bugs when accessing extent headers in various ext4 functions. These occur because extent headers can be freed by concurrent operations while other threads still hold pointers to them.
The issue is triggered by racing threads performing concurrent writes to the same file. After commit 665575cff098 ("filemap: move prefaulting out of hot write path"), the write path no longer prefaults pages in the hot path, creating a wider race window where:
1. Thread A calls ext4_find_extent() and gets a path with extent headers 2. Thread A's write attempt fails, entering the slow path 3. During the gap, Thread B modifies the extent tree, freeing nodes 4. Thread A continues using the now-freed extent headers, causing UAF
Fix this by validating the extent header in ext4_find_extent() before returning the path. This ensures all callers receive a valid extent path, fixing the race at a single point rather than adding checks throughout the codebase.
This addresses crashes in ext4_ext_insert_extent(), ext4_ext_binsearch(), and potentially other locations that use extent paths.
Reported-by: syzbot+9db318d6167044609878@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9db318d6167044609878 Fixes: 665575cff098 ("filemap: move prefaulting out of hot write path") Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey kartikey406@gmail.com --- fs/ext4/extents.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index ca5499e9412b..04ceae5b0a34 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4200,6 +4200,7 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode, unsigned int allocated_clusters = 0; struct ext4_allocation_request ar; ext4_lblk_t cluster_offset; + struct ext4_extent_header *eh;
ext_debug(inode, "blocks %u/%u requested\n", map->m_lblk, map->m_len); trace_ext4_ext_map_blocks_enter(inode, map->m_lblk, map->m_len, flags); @@ -4212,7 +4213,12 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode, }
depth = ext_depth(inode); - + eh = path[depth].p_hdr; + if (!eh || le16_to_cpu(eh->eh_magic) != EXT4_EXT_MAGIC) { + EXT4_ERROR_INODE(inode, "invalid extent header after find_extent"); + err = -EFSCORRUPTED; + goto out; + } /* * consistent leaf must not be empty; * this situation is possible, though, _during_ tree modification;
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue: KASAN: use-after-free Read in ext4_ext_correct_indexes
================================================================== BUG: KASAN: use-after-free in ext4_ext_correct_indexes+0x72/0x5b0 fs/ext4/extents.c:1712 Read of size 8 at addr ffff888078dca350 by task syz.2.45/6689
CPU: 0 UID: 0 PID: 6689 Comm: syz.2.45 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 ext4_ext_correct_indexes+0x72/0x5b0 fs/ext4/extents.c:1712 ext4_ext_insert_extent+0x1fdd/0x4af0 fs/ext4/extents.c:2188 ext4_ext_map_blocks+0x1bbe/0x3880 fs/ext4/extents.c:4410 ext4_map_create_blocks fs/ext4/inode.c:609 [inline] ext4_map_blocks+0x860/0x1740 fs/ext4/inode.c:811 _ext4_get_block+0x200/0x4c0 fs/ext4/inode.c:910 ext4_get_block_unwritten+0x2e/0x100 fs/ext4/inode.c:943 ext4_block_write_begin+0x990/0x1710 fs/ext4/inode.c:1198 ext4_write_begin+0xc04/0x19a0 fs/ext4/ext4_jbd2.h:-1 ext4_da_write_begin+0x445/0xda0 fs/ext4/inode.c:3129 generic_perform_write+0x2c2/0x900 mm/filemap.c:4175 ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:299 ext4_file_write_iter+0x298/0x1bc0 fs/ext4/file.c:-1 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c6/0xb30 fs/read_write.c:686 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x193/0x220 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f9e7b78e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9e7a9fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f9e7b9b5fa0 RCX: 00007f9e7b78e969 RDX: 000000000000fdef RSI: 0000200000000140 RDI: 0000000000000004 RBP: 00007f9e7b810ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000fecc R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f9e7b9b5fa0 R15: 00007fff3dade2a8 </TASK>
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888078dcadc0 pfn:0x78dca flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea00016119c8 ffffea00018708c8 0000000000000000 raw: ffff888078dcadc0 ffff888079136c60 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 0, migratetype Unmovable, gfp_mask 0x440dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_COMP), pid 6328, tgid 6328 (syz-executor), ts 132604632127, free_ts 133183234936 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21d5/0x22b0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 alloc_frozen_pages_noprof mm/mempolicy.c:2487 [inline] alloc_pages_noprof+0xa9/0x190 mm/mempolicy.c:2507 pagetable_alloc_noprof include/linux/mm.h:2881 [inline] __pte_alloc_one_noprof include/asm-generic/pgalloc.h:75 [inline] pte_alloc_one+0x21/0x170 arch/x86/mm/pgtable.c:18 __pte_alloc+0x25/0x1a0 mm/memory.c:452 copy_pte_range mm/memory.c:1107 [inline] copy_pmd_range+0x6a91/0x71d0 mm/memory.c:1261 copy_pud_range mm/memory.c:1298 [inline] copy_p4d_range mm/memory.c:1322 [inline] copy_page_range+0xc14/0x1270 mm/memory.c:1410 dup_mmap+0xf57/0x1ac0 mm/mmap.c:1834 dup_mm kernel/fork.c:1485 [inline] copy_mm+0x13c/0x4b0 kernel/fork.c:1537 copy_process+0x1706/0x3c00 kernel/fork.c:2179 kernel_clone+0x224/0x7c0 kernel/fork.c:2609 __do_sys_clone kernel/fork.c:2752 [inline] __se_sys_clone kernel/fork.c:2736 [inline] __x64_sys_clone+0x18b/0x1e0 kernel/fork.c:2736 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f page last free pid 920 tgid 920 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1395 [inline] __free_frozen_pages+0xbb1/0xd20 mm/page_alloc.c:2895 pagetable_free include/linux/mm.h:2898 [inline] pagetable_dtor_free include/linux/mm.h:2996 [inline] __tlb_remove_table+0x2d2/0x3b0 include/asm-generic/tlb.h:220 __tlb_remove_table_free mm/mmu_gather.c:227 [inline] tlb_remove_table_rcu+0x85/0x100 mm/mmu_gather.c:290 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_call_function_single arch/x86/kernel/smp.c:266 [inline] sysvec_call_function_single+0xa3/0xc0 arch/x86/kernel/smp.c:266 asm_sysvec_call_function_single+0x1a/0x20 arch/x86/include/asm/idtentry.h:709
Memory state around the buggy address: ffff888078dca200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888078dca280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888078dca300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^ ffff888078dca380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888078dca400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ==================================================================
Tested on:
commit: 755fa5b4 Merge tag 'cgroup-for-6.18' of git://git.kern.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14fea42c580000 kernel config: https://syzkaller.appspot.com/x/.config?x=9c0c1e13e3c8731f dashboard link: https://syzkaller.appspot.com/bug?extid=9db318d6167044609878 compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8 patch: https://syzkaller.appspot.com/x/patch.diff?x=16fb6942580000
linux-stable-mirror@lists.linaro.org