CVE-2022-49220 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
dax: make sure inodes are flushed before destroy cache
A bug can be triggered by following command
$ modprobe nd_pmem && modprobe -r nd_pmem
[ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()
[ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)
[ 10.062433] Call Trace:
[ 10.062673] dump_stack_lvl+0x34/0x44
[ 10.062865] slab_err+0x90/0xd0
[ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0
[ 10.063848] kmem_cache_destroy+0x4a/0x110
[ 10.064058] __x64_sys_delete_module+0x265/0x300
This is caused by dax_fs_exit() not flushing inodes before destroy cache. To fix this issue, call rcu_barrier() before destroy cache.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/21/2025
The vulnerability described in CVE-2022-49220 resides within the Linux kernel's Direct Access DAX (DAX) subsystem, specifically concerning memory management operations during module unloading. This issue manifests when the nd_pmem kernel module is dynamically loaded and subsequently unloaded, creating a race condition or memory management inconsistency that leads to kernel panic conditions. The problem occurs during the module removal process where the kernel attempts to clean up DAX cache structures without properly ensuring that all pending inode operations are completed first. The error message indicates that objects remain in the dax_cache during kernel memory cache shutdown, suggesting that the cleanup process fails to properly synchronize with ongoing operations that may be holding references to cached memory regions.
The technical flaw stems from improper synchronization within the dax_fs_exit() function which handles filesystem cleanup operations when the DAX subsystem is being shut down. When the nd_pmem module is removed, the function fails to ensure that all inodes associated with DAX-backed memory regions are properly flushed and synchronized before proceeding with cache destruction. This creates a scenario where memory objects remain in the kernel's slab allocator even though the cache structure itself is being destroyed, leading to the kernel panic condition reported in the stack trace. The issue is particularly concerning because it represents a memory management inconsistency that can result in system instability and potential denial of service conditions when the kernel attempts to clean up resources during module operations.
From an operational perspective, this vulnerability presents significant risks to systems relying on DAX functionality for high-performance storage operations, particularly in environments using persistent memory or non-volatile memory modules. The condition can be reliably triggered through simple module loading and unloading operations, making it exploitable in scenarios where modules are frequently loaded and unloaded or during system maintenance operations. The vulnerability's impact extends beyond simple system crashes to potentially compromise data integrity in persistent memory environments where proper synchronization of memory operations is critical for maintaining data consistency. Systems using DAX for storage acceleration or memory-mapped file operations are particularly vulnerable, as the flaw can cause unexpected system termination during normal module lifecycle operations.
The fix implemented addresses this vulnerability by introducing proper synchronization mechanisms through the addition of rcu_barrier() calls before cache destruction operations. This ensures that all pending RCU (Read-Copy-Update) operations and inode flushes are completed before the DAX cache structures are destroyed, preventing the scenario where objects remain in the cache during shutdown. The solution aligns with established kernel memory management practices and follows the principle of proper resource cleanup synchronization. This vulnerability can be mapped to CWE-129, which covers improper limitation of a recognized operating system command, and also relates to CWE-362, which addresses race conditions in concurrent execution environments. From an ATT&CK perspective, this issue could be categorized under T1490 for denial of service attacks, potentially enabling attackers to cause system instability through module manipulation, though the specific attack vector requires careful exploitation of the module loading/unloading sequence. The fix demonstrates proper kernel development practices for handling memory management operations and ensures that subsystem cleanup operations properly account for pending operations before resource destruction.