CVE-2026-53272

What it actually does

This is a Linux kernel use-after-free in the EROFS compressed filesystem path. A race can occur between asynchronous decompression work scheduled after I/O completion and filesystem unmount cleanup. If the EROFS superblock private data is freed during unmount while queued decompression code later dereferences sbi->sync_decompress, the kernel may access freed memory. The most likely impact is kernel memory corruption leading to a crash or denial of service; depending on allocator behavior, timing, and available memory-reuse primitives, kernel privilege escalation may be theoretically possible, but no public exploitation is indicated by the provided intelligence.

Why it matters to the business

Systems that mount compressed EROFS images could be exposed to local denial-of-service risk if an attacker can trigger repeated mount, I/O, decompression, and unmount activity. Operational consequences may include unexpected host reboots, service disruption, failed container or appliance workloads that rely on EROFS images, and incident response effort to distinguish crashes from hardware or stability issues. Current exploitation urgency appears low because EPSS is very low, the issue is not listed in KEV, and no exploit maturity is reported; however, kernel flaws should still be remediated through normal kernel update cycles because successful exploitation can affect the whole host.

How an attack unfolds

An attacker first needs a way to interact with EROFS filesystem handling on a vulnerable Linux kernel, typically through local access, a workload that can cause EROFS images to be mounted, or an environment where untrusted filesystem images are processed. The attacker prepares or uses a compressed EROFS filesystem and triggers I/O that causes z_erofs_endio() to schedule asynchronous decompression work. The attacker then attempts to win a race by causing the filesystem to be unmounted while decompression work is still pending or completing. During unmount, EROFS cleanup frees the superblock private data. If the queued decompression path later accesses sbi->sync_decompress, it dereferences freed memory. In practical terms, repeated attempts would likely be used to cause a kernel oops, panic, or host instability. More advanced exploitation would require shaping freed kernel memory so that the stale pointer access produces controlled behavior, but no public exploit or active campaign is indicated.

How to fix it

Apply the Linux kernel update containing the upstream EROFS fix for the sbi->sync_decompress use-after-free. Because no affected distribution package list or exact fixed versions were provided, use the security advisory and kernel package channels for each Linux distribution or vendor appliance to identify the corrected kernel build. Prioritize systems that mount EROFS images, use compressed read-only filesystem images, process untrusted filesystem media, run container or embedded workloads based on EROFS, or permit users to mount filesystem images. If immediate patching is not possible, reduce exposure by preventing untrusted users from mounting filesystem images, restricting loop-device and mount privileges, disabling or avoiding EROFS image processing where operationally feasible, and limiting access to workloads that can trigger EROFS mount/unmount activity. Reboot into the updated kernel after patching; installing a kernel package alone is not sufficient until the running kernel is replaced.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version, not only the installed package version, against the vendor advisory for this vulnerability. Check whether EROFS support is present by reviewing loaded modules and kernel configuration, such as lsmod for erofs or z_erofs entries and /boot/config-* for CONFIG_EROFS_FS and compression-related EROFS options. Validate that systems requiring EROFS can mount and unmount compressed images without kernel warnings after the update. For exposure assessment, identify hosts that have mounted EROFS filesystems using mount output, /proc/mounts, audit logs, container/runtime logs, appliance image-management logs, or EDR telemetry showing mount/umount activity involving erofs. If kernel live patching is used, confirm the live patch specifically includes this EROFS race fix or reboot to a fully fixed kernel.

Typical attack path

1. Gain local execution or influence over a component that mounts or processes EROFS filesystem images.
2. Provide or select a compressed EROFS image that exercises the decompression I/O path.
3. Trigger reads that complete asynchronously and cause z_erofs_endio() to queue z_erofs_decompress_kickoff() / z_erofs_decompressqueue_work().
4. Rapidly trigger filesystem unmount while queued decompression work may still reference EROFS superblock state.
5. Repeat the race until the freed sbi structure is accessed through sbi->sync_decompress.
6. Observe kernel crash, service outage, or other memory-corruption side effects; in a more sophisticated scenario, attempt to shape kernel heap reuse for privilege escalation.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel logs, crash dumps, audit records, and EDR telemetry. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg archives, systemd-coredump metadata, kdump/vmcore analysis, auditd mount/umount events, container/runtime logs, and endpoint telemetry for repeated mount and unmount operations involving EROFS or loop devices. Investigate kernel oops, panic, KASAN, KFENCE, UBSAN, general protection fault, slab-use-after-free, or page fault messages that reference EROFS functions such as z_erofs_decompress_kickoff, z_erofs_decompressqueue_work, z_erofs_endio, erofs_kill_sb, or erofs_sb_free. A suspicious pattern is repeated EROFS mount/read/unmount activity shortly before kernel crashes or warnings. Because this is a race-condition memory-corruption bug, there may be no durable file artifact after a crash; absence of logs does not rule out exploitation if logs were lost during panic or reboot.

• z_erofs_decompress_kickoff
• z_erofs_decompressqueue_work
• z_erofs_endio
• erofs_kill_sb
• erofs_sb_free
• sbi->sync_decompress
• EROFS
• erofs
• BUG: KASAN: slab-use-after-free
• BUG: KASAN: use-after-free
• KFENCE: use-after-free
• general protection fault
• kernel NULL pointer dereference
• kernel BUG at
• Oops:
• Kernel panic
• mount -t erofs
• type=erofs
• /proc/mounts
• /var/log/kern.log
• /var/log/messages
• journalctl -k

What your security team should do

• Prioritize inventory: identify Linux systems with EROFS enabled or actively mounting EROFS images, especially multi-user systems, container hosts, embedded devices, build systems, and appliances.
• Patch vulnerable kernels through vendor-supported updates and reboot into the fixed kernel; track completion by running kernel version.
• Treat systems that allow untrusted users or workloads to mount filesystem images as higher priority, even though current EPSS and exploit maturity are low.
• Temporarily restrict mount, loop device, FUSE-adjacent workflows, and filesystem-image processing privileges where untrusted input is possible.
• Add monitoring for kernel oops, panic, KASAN, or general-protection-fault events referencing EROFS decompression functions.
• Review recent crash dumps and kernel logs for EROFS-related faults before concluding instability is unrelated.
• If using immutable images, embedded firmware, or container infrastructure based on EROFS, coordinate updates with platform, DevOps, and device-management teams to ensure fixed kernels are deployed everywhere.
• Do not rely on package installation state alone; verify that hosts have rebooted or otherwise transitioned to the corrected running kernel.