CVE-2026-53129

What it actually does

This is a Linux kernel use-after-free in the mbcache code used by filesystems such as ext2, ext4, and ocfs2. A pending or running cache shrink work item can outlive destruction of the mbcache object: mb_cache_destroy() frees shrinker state, cache entries, and the cache itself without first synchronizing with c_shrink_work. If a privileged user triggers cache entry creation and then triggers the final release of a mounted affected filesystem while shrink work is pending or executing, the worker may dereference freed kernel memory. The practical impact is most likely a local kernel crash or denial of service; depending on kernel configuration, heap state, and exploitation reliability, use-after-free conditions may sometimes be considered for privilege-impacting exploitation, but this issue is described as reachable only by root or a user with CAP_SYS_ADMIN.

Why it matters to the business

The primary business risk is disruption of Linux systems through a kernel crash or instability caused by a privileged local action involving mounted ext2, ext4, or ocfs2 filesystems. Because exploitation requires root or CAP_SYS_ADMIN and there is no known public exploit or CISA KEV listing, internet-scale remote exploitation risk is low; however, the bug still matters for multi-user Linux systems, container hosts, build infrastructure, appliances, and environments where delegated mount or namespace capabilities are granted. A successful trigger could interrupt applications, cause node reboots, or reduce availability of services running on affected kernels.

How an attack unfolds

An attacker must already have privileged local execution, such as root access or CAP_SYS_ADMIN. They prepare or interact with a mounted ext2, ext4, or ocfs2 filesystem in a way that causes mb_cache_entry_create() to schedule the asynchronous mbcache shrink worker. Before that worker has completed, they trigger teardown of the filesystem state, such as by causing the final reference to the mounted filesystem cache to be released. In vulnerable kernels, mb_cache_destroy() can free the cache and associated structures without canceling and synchronizing the pending c_shrink_work item. When mb_cache_shrink_worker() later runs or continues running, it touches memory that has already been freed, producing a kernel use-after-free. Observable outcomes are likely to include a kernel oops, panic, KASAN use-after-free report, filesystem-related instability, or a system reboot. No public exploit maturity is reported, EPSS is very low, and the issue is not currently known to be used in ransomware campaigns or listed in KEV.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix to cancel the pending mbcache shrink work with cancel_work_sync() before freeing shrinker state and destroying the cache. Where exact package versions are not available, upgrade to the latest supported kernel from the operating system or appliance vendor and reboot into the updated kernel. Prioritize systems where untrusted users, containers, build jobs, or automation can obtain CAP_SYS_ADMIN, perform mounts, use user namespaces with mount capability, or manipulate ext2/ext4/ocfs2 filesystems. If immediate patching is not possible, reduce exposure by restricting CAP_SYS_ADMIN, disabling unprivileged user namespaces where operationally feasible, limiting mount/unmount privileges, preventing untrusted loopback filesystem mounting, and avoiding use of affected filesystem workflows by untrusted privileged workloads.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the mbcache destruction path, not merely that an updated package is installed. Validate by checking the active kernel version after reboot with uname -r and comparing it to the vendor advisory or fixed package changelog for this issue. If building from source, confirm fs/mbcache.c synchronizes c_shrink_work with cancel_work_sync() before shrinker_free() and cache teardown in mb_cache_destroy(). Review whether systems allow non-administrative workloads to obtain CAP_SYS_ADMIN or mount ext2/ext4/ocfs2 filesystems; those systems remain higher priority until patched. After remediation, monitor for absence of recurring kernel oops, panic, KASAN, or mbcache-related messages during filesystem mount/unmount and workload tests.

Typical attack path

1. Obtain privileged local access to a Linux host, or gain CAP_SYS_ADMIN in a context where mounting or unmounting affected filesystems is possible.
2. Mount or otherwise operate on an ext2, ext4, or ocfs2 filesystem that uses mbcache.
3. Trigger mbcache entry creation and shrink work scheduling through filesystem activity.
4. Race filesystem/cache teardown so mb_cache_destroy() runs while the mbcache shrink worker is pending or active.
5. Cause the stale shrink worker to access freed mbcache memory.
6. Leverage the resulting condition primarily to crash or destabilize the kernel, or attempt further memory-corruption exploitation if conditions are favorable.

How to detect it

Retrospective detection should focus on kernel and crash telemetry rather than network indicators, because exploitation requires privileged local access and does not have a remote protocol signature. Review journald, syslog, dmesg, kernel ring buffer captures, crash dumps, kdump/vmcore records, and EDR telemetry for kernel oops, panic, KASAN, or use-after-free reports mentioning mbcache functions, filesystem unmount activity, or ext2/ext4/ocfs2 operations. Correlate suspicious events with privileged actions such as mount, umount, loop device setup, container launches with --privileged or CAP_SYS_ADMIN, namespace creation, and filesystem image handling. Investigate crashes where call traces include mb_cache_destroy(), mb_cache_shrink_worker(), shrinker_free(), process_one_work(), or ext4/ocfs2 teardown paths. Also review auditd logs for mount and unmount syscalls by unexpected users, service accounts, containers, CI jobs, or automation around the time of kernel instability. Absence of these artifacts does not prove non-exploitation, especially if kernel logs are not persistent across reboot.

• mb_cache_destroy
• mb_cache_shrink_worker
• c_shrink_work
• fs/mbcache.c
• BUG: KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at fs/mbcache.c
• Oops:
• Kernel panic - not syncing
• workqueue:
• process_one_work
• shrinker_free
• EXT4-fs
• EXT2-fs
• ocfs2
• audit: type=SYSCALL msg= syscall=mount
• audit: type=SYSCALL msg= syscall=umount2
• CAP_SYS_ADMIN
• losetup
• mount -t ext4
• mount -t ext2
• mount -t ocfs2

What your security team should do

• Patch and reboot affected Linux systems through normal kernel update channels, prioritizing shared compute, container hosts, CI/CD runners, virtualization hosts, and systems where CAP_SYS_ADMIN is delegated.
• Inventory hosts that allow user namespaces, privileged containers, loop device mounting, or untrusted ext2/ext4/ocfs2 image handling, because these increase practical reachability.
• Restrict CAP_SYS_ADMIN and privileged container use to trusted workloads only; treat CAP_SYS_ADMIN as effectively equivalent to broad host control.
• Temporarily disable or tightly control unprivileged filesystem mounting and loopback image processing where patching is delayed.
• Review kernel logs for recent crashes or memory-safety reports involving mbcache, ext4, ext2, ocfs2, shrinkers, or workqueues.
• Ensure crash dump collection, kdump, and centralized kernel logging are enabled on critical Linux systems to support retrospective analysis.
• Track operating system vendor advisories for the exact fixed kernel package because fixed versions vary by distribution and support branch.