CVE-2025-38172

What it actually does

Use-after-free in erofs filesystem mount handling when primary device is a block device and extra device is file-backed, causing erofs_init_device to return ENOTBLK (ignored in erofs_fc_get_tree) followed by deactivate_locked_super freeing sbi and subsequent filp_open write to freed structure.

Why it matters to the business

Kernel instability or potential code execution on Linux systems using erofs with multiple devices; widespread impact given Linux kernel prevalence across servers, embedded, and cloud workloads, though exploitation requires specific device configuration.

How an attack unfolds

Attacker supplies an erofs mount request with mismatched device types (block primary, file-backed extra) to trigger ENOTBLK return path in erofs_fc_get_tree, leading to sbi free-then-use sequence during superblock initialization.

How to fix it

Upgrade Linux kernel to commit 65115472f741ca000d7ea4a5922214f93cd1516e or later stable releases containing the fix that converts ENOTBLK to -EINVAL in erofs_init_device error handling.

How to confirm the fix worked

Verify kernel source contains the erofs error conversion logic or confirm running kernel version includes the referenced commit; test mount operations with mixed device types to ensure -EINVAL is returned instead of proceeding to UAF.

Typical attack path

1. Prepare erofs filesystem image and mismatched device files (block vs regular file)
2. Invoke mount syscall or mount command targeting erofs with multiple devices
3. Trigger erofs_fc_get_tree -> get_tree_bdev_flags -> erofs_read_superblock -> erofs_init_device returning ENOTBLK
4. deactivate_locked_super frees sbi while erofs_fc_get_tree continues to access sbi->dif0
5. Achieve UAF write via subsequent filp_open assignment

How to detect it

Review kernel logs for erofs mount failures involving ENOTBLK or device type mismatches; inspect auditd or dmesg entries around mount syscalls targeting erofs; correlate with unexpected superblock deallocation patterns.

What your security team should do

• Apply kernel update containing commit 65115472f741ca000d7ea4a5922214f93cd1516e immediately on all systems using erofs
• Audit erofs mount configurations and disable multi-device setups until patched
• Monitor kernel update channels for stable backports and schedule distribution-wide rollout
• Review any custom erofs tooling or initramfs that may trigger the mount path