CVE-2026-53129 in Linux
Summary
by MITRE • 06/24/2026
In the Linux kernel, the following vulnerability has been resolved:
fs/mbcache: cancel shrink work before destroying the cache
mb_cache_destroy() calls shrinker_free() and then frees all cache entries and the cache itself, but it does not cancel the pending c_shrink_work work item first.
If mb_cache_entry_create() schedules c_shrink_work via schedule_work() and the work item is still pending or running when mb_cache_destroy() runs, mb_cache_shrink_worker() will access the cache after its memory has been freed, causing a use-after-free.
This is only reachable by a privileged user (root or CAP_SYS_ADMIN) who can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem.
Cancel the work item with cancel_work_sync() before calling shrinker_free(), ensuring the worker has finished and will not be rescheduled before the cache is torn down.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 06/24/2026
The vulnerability resides in the Linux kernel's metadata block cache implementation within the file system subsystem, specifically affecting how cache destruction is handled during filesystem unmount operations. This issue represents a classic use-after-free condition that occurs when the system attempts to free memory resources while background work items may still be accessing those same resources. The problem manifests in the mb_cache_destroy() function which manages the cleanup of metadata block caches used by ext2, ext4, and ocfs2 filesystems. When a filesystem is unmounted, this function is responsible for releasing all cache entries and the cache structure itself.
The technical flaw stems from improper synchronization between the cache destruction process and pending work items that may still be scheduled or executing in the background. The mb_cache_entry_create() function schedules c_shrink_work using schedule_work() which creates a race condition with mb_cache_destroy(). During normal operation, when a filesystem is unmounted and the cache needs to be destroyed, the system calls shrinker_free() before properly canceling the pending c_shrink_work item. This sequence leaves open the possibility that mb_cache_shrink_worker() will attempt to access memory that has already been freed by the destruction process.
The operational impact of this vulnerability is significant as it can lead to system instability and potential privilege escalation. The attack vector requires privileged access since only root or processes with CAP_SYS_ADMIN capability can trigger the specific conditions that lead to this scenario. This typically occurs during filesystem unmount operations when the last reference to a mounted filesystem is released, making it particularly relevant for system administrators managing multiple filesystems or automated unmount processes. The vulnerability creates a condition where memory corruption can occur through the use-after-free pattern, potentially allowing malicious actors with root privileges to execute arbitrary code or cause denial of service conditions.
This vulnerability maps directly to CWE-416 Use After Free, which is categorized under the Common Weakness Enumeration framework for memory safety issues in software systems. From an adversarial perspective, this aligns with ATT&CK technique T1068, which involves exploit development through privilege escalation by leveraging system vulnerabilities. The fix implemented addresses this issue by introducing cancel_work_sync() before shrinker_free() is called, ensuring that all pending c_shrink_work items are properly canceled and their execution completed before the cache memory is freed. This approach follows standard kernel development practices for proper resource cleanup in concurrent systems, preventing the race condition between background work processing and resource deallocation.
The mitigation strategy focuses on ensuring proper synchronization between work queue operations and resource destruction processes. The solution requires calling cancel_work_sync() which not only cancels pending work items but also waits for any currently executing work item to complete before proceeding with cache destruction. This prevents the scenario where a worker thread might attempt to access freed memory, thereby eliminating the use-after-free condition that could lead to system crashes or potential exploitation. The fix is implemented at the kernel level and requires no user intervention, as it addresses the root cause within the filesystem subsystem's cache management logic.