CVE-2022-50845 in Linux
Summary
by MITRE • 12/30/2025
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix inode leak in ext4_xattr_inode_create() on an error path
There is issue as follows when do setxattr with inject fault:
[localhost]# fsck.ext4 -fn /dev/sda
e2fsck 1.46.6-rc1 (12-Sep-2022) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Unattached zero-length inode 15. Clear? no
Unattached inode 15 Connect to /lost+found? no
Pass 5: Checking group summary information
/dev/sda: ********** WARNING: Filesystem still has errors **********
/dev/sda: 15/655360 files (0.0% non-contiguous), 66755/2621440 blocks
This occurs in 'ext4_xattr_inode_create()'. If 'ext4_mark_inode_dirty()' fails, dropping i_nlink of the inode is needed. Or will lead to inode leak.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 04/26/2026
The vulnerability CVE-2022-50845 represents a critical inode leak issue within the ext4 filesystem implementation of the Linux kernel, specifically affecting the ext4_xattr_inode_create() function during error handling scenarios. This flaw manifests when the setxattr system call is executed with fault injection, creating conditions where filesystem metadata becomes corrupted and unrecoverable. The issue stems from inadequate error path handling in the extended attribute inode creation process, where proper cleanup operations are not performed when critical operations fail. The vulnerability is particularly concerning because it leads to filesystem inconsistency and can result in data loss or corruption that requires manual intervention through filesystem repair utilities like fsck.ext4.
The technical root cause of this vulnerability lies in the failure to properly manage inode reference counts during error conditions within the ext4_xattr_inode_create() function. When ext4_mark_inode_dirty() fails during extended attribute creation, the system should decrement the inode's link count to prevent orphaned inodes, but this cleanup operation is omitted. This oversight creates a scenario where inodes become "unattached" and remain in the filesystem structure without proper reference tracking, as evidenced by the fsck.ext4 output showing "Unattached zero-length inode 15" and "Unattached inode 15" messages. The issue demonstrates a classic resource management flaw where temporary filesystem structures are not properly released, leading to persistent metadata inconsistencies that can accumulate over time and eventually render filesystem operations unreliable.
The operational impact of CVE-2022-50845 extends beyond simple filesystem corruption, potentially affecting system stability and data integrity across Linux systems utilizing ext4 filesystems. When this vulnerability is exploited through fault injection techniques during setxattr operations, it creates persistent inode leaks that can accumulate and eventually cause filesystem errors that require manual intervention. The vulnerability's manifestation in the fsck.ext4 output indicates that the filesystem remains in an inconsistent state, with the repair utility reporting "Filesystem still has errors" and showing that the system cannot automatically resolve the inode attachment issues. This behavior aligns with CWE-459, which describes incomplete cleanup vulnerabilities where resources are not properly released, and reflects patterns commonly seen in the ATT&CK framework under privilege escalation and persistence techniques that leverage filesystem corruption for continued system access.
Mitigation strategies for CVE-2022-50845 should focus on immediate kernel updates that implement proper error handling in the ext4_xattr_inode_create() function, ensuring that inode reference counts are properly managed even during error conditions. System administrators should monitor filesystem health regularly using tools like fsck.ext4 and implement preventive measures such as regular filesystem checks and proper backup procedures to minimize data loss risks. The fix requires careful implementation of proper cleanup routines that decrement inode link counts when ext4_mark_inode_dirty() operations fail, preventing the accumulation of orphaned inodes that can lead to filesystem instability. Additionally, organizations should consider implementing monitoring solutions that can detect filesystem corruption patterns and alert administrators to potential inode leak conditions before they escalate into more serious system failures, particularly in environments where extended attribute operations are frequently performed.