Message-ID: <dd5c923.1fc4a.19a5475534a.Coremail.l1zao@zju.edu.cn>
Date: Wed, 5 Nov 2025 22:39:26 +0800 (GMT+08:00)
From: 章怿贺 <l1zao@....edu.cn>
To: security@...nel.org, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [SECURITY] ext4: KASAN use-after-free and Oops in
 ext4_xattr_set_entry with crafted ext4 image

Hi,







I would like to report a potential security issue in the Linux kernel ext4 filesystem, which I found using a modified syzkaller-based kernel fuzzing tool that I developed.










Summary




-------







A local unprivileged user who can mount a crafted ext4 filesystem image and call lsetxattr() on a file inside that filesystem can trigger:







1) an Oops in memcpy_orig() called from ext4_xattr_set_entry(), and




2) a subsequent KASAN-reported slab-use-after-free in rwsem_down_write_slowpath().







The bug is triggered by a crafted ext4 image combined with a trusted.overlay.upper extended attribute set on a file in that filesystem.







I could not find an existing CVE that exactly matches this behavior (though I am aware of CVE-2018-10879, CVE-2019-19319, CVE-2019-19767 and CVE-2024-40972, which also involve ext4_xattr_set_entry()). Could you please help confirm whether this is a new vulnerability or a duplicate of a known issue?













Environment




-----------







- Kernel version: 6.12.51 (built with KASAN, PREEMPT, SMP, NOPTI)




- Architecture: x86_64

- Hypervisor: QEMU (Standard PC i440FX + PIIX, BIOS 1.13.0-1ubuntu1.1)

- Filesystem: ext4, mounted from a crafted disk image via /dev/loopN

- Quota mode: writeback

- No journal (mounted r/w without journal)













Symptoms and logs




-----------------







When running the syzkaller reproducer, the kernel hits an Oops in memcpy_orig() from ext4_xattr_set_entry(), followed by file system corruption messages and a KASAN use-after-free report in rwsem_down_write_slowpath().







Relevant part of the first Oops:










    BUG: unable to handle page fault for address: ff1100010f590fe4




    #PF: supervisor write access in kernel mode

    #PF: error_code(0x0003) - permissions violation

    CPU: 2 UID: 0 PID: 1396 Comm: syz.3.37 Not tainted 6.12.51 #3

    RIP: 0010:memcpy_orig+0x31/0x140 arch/x86/lib/memcpy_64.S:71

      ...

    Call Trace:

      ext4_xattr_set_entry+0x10ba/0x17e0 fs/ext4/xattr.c:1813

      ext4_xattr_ibody_set+0x380/0x570 fs/ext4/xattr.c:2283

      ext4_xattr_set_handle+0xa16/0x14d0 fs/ext4/xattr.c:2455

      ext4_xattr_set+0x1e1/0x3a0 fs/ext4/xattr.c:2569

      __vfs_setxattr+0x13e/0x1b0 fs/xattr.c:200

      vfs_setxattr+0x12e/0x330 fs/xattr.c:321

      do_setxattr+0x134/0x1e0 fs/xattr.c:629

      path_setxattr+0x1da/0x220 fs/xattr.c:658

      __x64_sys_lsetxattr+0xc1/0x160 fs/xattr.c:679







After that, ext4 reports block bitmap corruption:










    EXT4-fs error (device loop3): ext4_validate_block_bitmap:440:




      comm syz-executor: bg 0: block 169: padding at end of block bitmap is not set

    EXT4-fs error (device loop3) in ext4_mb_clear_bb:6545: Corrupt filesystem







Then KASAN reports a use-after-free in rwsem_down_write_slowpath():










    BUG: KASAN: slab-use-after-free in owner_on_cpu include/linux/sched.h:2185 [inline]




    BUG: KASAN: slab-use-after-free in rwsem_can_spin_on_owner kernel/locking/rwsem.c:723 [inline]

    BUG: KASAN: slab-use-after-free in rwsem_down_write_slowpath+0x1064/0x1110 kernel/locking/rwsem.c:1111

    Read of size 4 at addr ff1100010a11c5f4 by task syz-executor/859

      ...

    The buggy address belongs to the object at ff1100010a11c5c0 which belongs to the cache task_struct of size 5640

    The buggy address is located 52 bytes inside of freed 5640-byte region [ff1100010a11c5c0, ff1100010a11dbc8)













Reproducer




----------







The issue is reproducible with a syzkaller program and the generated C reproducer.




The reproducer performs roughly the following steps:







1. Use syz_mount_image$ext4 to mount a crafted ext4 image on ./file1 via /dev/loopN,




   with options "norecovery,debug_want_extra_isize=0x3e" and with errors=continue

   added by syzkaller’s helper.

2. Call lchown("./file1", 0, 0) on the mounted path.

3. Call lsetxattr("./file1", "trusted.overlay.upper", buf, 0xe1, 0).







I am attaching (or linking) the full syzkaller reproducer and the autogenerated C reproducer for convenience:







- syzkaller program (human-readable form)




- C reproducer (auto-generated by syzkaller)







I have attached the crash log and a PoC as separate files for your reference.













Security impact




---------------







From my understanding, this is at least a local denial-of-service issue




(kernel crash / panic) reachable by an unprivileged local user who can:







- supply or access a crafted ext4 filesystem image, and




- mount it (for example, via a loop device, container environment, or with

  user namespaces, depending on system configuration), and

- call lsetxattr() on the crafted file.







Because KASAN reports a slab use-after-free involving task_struct objects, I am not sure whether this can be further exploited for privilege escalation, but in principle it looks like a memory corruption bug.







Request




-------







Could you please:










1. Confirm whether this is a new issue or a duplicate of any existing ext4 xattr-related CVE (e.g., CVE-2018-10879, CVE-2019-19319, CVE-2019-19767, CVE-2024-40972), and

2. Advise on the correct fix / commit, once identified?







If it is considered a new security vulnerability, I would like to request or coordinate a CVE ID for it and will reference the relevant patch / mailing list thread in the CVE description.







Thank you very much for your time and for maintaining ext4.










Best regards,




YiHe Zhang




Zhejiang University



Content of type "text/html" skipped

View attachment "poc.txt" of type "text/plain" (39545 bytes)

View attachment "log.txt" of type "text/plain" (11409 bytes)

Powered by blists - more mailing lists