CVE-2024-45003 is a vulnerability in the Linux kernel related to inode eviction and reclaiming processes that can lead to deadlocks during inode management. The Linux kernel uses an inode reclaiming process to free up memory by collecting reclaimable inodes and marking them with the I_FREEING flag. During this process, other processes attempting to access these inodes become blocked. The vulnerability arises when certain filesystems, such as ext4 with the ea_inode feature or ubifs with extended attributes (xattr), perform inode lookups during the inode eviction callback while the inode LRU (Least Recently Used) list is being traversed. This can cause deadlocks because the reclaiming process holds locks while trying to evict inodes, and the inode lookup attempts to acquire locks on inodes that are already marked as freeing, causing processes to wait indefinitely. Two main deadlock scenarios are described: 1. Ext4 Filesystem Deadlock: When the ext4_evict_inode() function is called, it may trigger an extended attribute inode lookup (ea_inode) that attempts to access an inode already marked for eviction. This leads to a deadlock where the reclaiming process cannot complete because it waits on the inode state to change, but the inode lookup is blocked waiting for the reclaiming process to finish. 2. UBIFS Filesystem Deadlock: In the ubifs_jnl_write_inode() function, a race condition occurs involving the BASEHD's write buffer mutex (wbuf->io_mutex). The file deleting process holds this mutex while trying to get the xattr inode, which races with the inode reclaiming process that also tries to lock the same mutex during inode eviction. This results in an ABBA deadlock pattern where two processes wait on each other’s locks, halting progress. The fix introduces a new inode state flag, I_LRU_ISOLATING, which pins the inode in memory during the isolation phase to prevent these deadlocks by ensuring that inode lookups do not block reclaiming operations. This change improves the concurrency and stability of inode eviction and reclaiming in affected filesystems. This vulnerability affects Linux kernel versions identified by the commit hash e50e5129f384ae282adebfb561189cdb19b81cee and related versions prior to the patch. No known exploits are currently reported in the wild.

For European organizations, this vulnerability can lead to system hangs or deadlocks on Linux servers and devices using affected filesystems (ext4 with ea_inode feature, ubifs with xattr). These deadlocks can cause denial of service (DoS) conditions by blocking critical filesystem operations, potentially impacting availability of services relying on Linux infrastructure. Given Linux's widespread use in enterprise servers, cloud environments, embedded devices, and IoT systems across Europe, the impact could be significant in environments with heavy filesystem activity or where extended attributes are used extensively. The deadlock could disrupt operations in data centers, web hosting, telecommunications infrastructure, and industrial control systems. Systems performing frequent file attribute operations or cache management (e.g., via drop_caches) are particularly at risk. While this vulnerability does not directly expose confidentiality or integrity risks, the resulting DoS could indirectly affect business continuity and operational resilience. Organizations relying on Linux-based storage solutions or embedded Linux devices should be aware of potential service interruptions until patched.

1. Apply Kernel Updates: The primary mitigation is to update Linux kernels to versions that include the patch introducing the I_LRU_ISOLATING flag. Organizations should monitor distributions for security advisories and apply vendor-provided kernel updates promptly. 2. Filesystem Configuration Review: Evaluate the use of extended attributes (xattr) and the ea_inode feature on ext4 filesystems. Where feasible, disable or limit these features if not required, reducing exposure. 3. Controlled Cache Management: Avoid aggressive or frequent use of cache dropping commands (e.g., echo 2 > /proc/sys/vm/drop_caches) in production environments, as these can trigger inode reclaiming and increase deadlock risk. 4. Monitoring and Alerting: Implement monitoring for kernel hangs, inode reclaiming stalls, or filesystem deadlocks. Tools that detect kernel lockups or high inode reclaim activity can provide early warning. 5. Testing Before Deployment: Test kernel updates and filesystem configurations in staging environments to ensure stability and compatibility, especially for systems using ubifs or ext4 with extended attributes. 6. Incident Response Preparedness: Prepare for potential DoS scenarios by having recovery procedures, including safe reboot strategies and filesystem checks, to minimize downtime if deadlocks occur.