CVE-2022-50845

What it actually does

Failure to decrement i_nlink in ext4_xattr_inode_create() when ext4_mark_inode_dirty() fails leaves a zero-length inode unattached, visible as fsck errors reporting unattached inodes.

Why it matters to the business

Systems may experience file system inconsistencies requiring manual repair, increasing downtime and administrative effort; low exploitability and stable low EPSS reduce immediate operational risk despite the 305-day-old disclosure.

How an attack unfolds

An attacker with local write access triggers setxattr operations while inducing faults that cause ext4_mark_inode_dirty() to fail inside ext4_xattr_inode_create(), resulting in the leaked inode; no named threat actors or ransomware campaigns are associated.

How to fix it

Upgrade Linux kernel to commit 0f709e08caffb41bbc9b38b9a4c1bd0769794007 or later; for listed Debian chromium packages apply 71.0.3578.80-1 or newer packages that incorporate the fix.

How to confirm the fix worked

Run fsck.ext4 -fn on affected file systems before and after patching to confirm absence of unattached zero-length inodes; verify kernel version contains the referenced commit.

Typical attack path

1. Obtain local access to a system using the vulnerable ext4 implementation
2. Perform setxattr calls while injecting faults that cause ext4_mark_inode_dirty() to fail
3. Observe resulting unattached zero-length inodes via fsck or kernel logs
4. Leverage accumulated leaked inodes to trigger file-system errors or resource exhaustion

How to detect it

Review kernel logs and fsck output for messages about unattached zero-length inodes or ext4_xattr_inode_create errors; no specific threat-actor artifacts are known.

What your security team should do

• Prioritize kernel upgrades on all ext4 systems within standard change windows given low EPSS and absence from KEV
• Enable regular fsck scans on ext4 volumes to detect inode leaks proactively
• Monitor for future EPSS increases or KEV inclusion that would accelerate patching timelines