CVE-2026-89723

What it actually does

Slab-out-of-bounds memory access in nilfs2 B-tree handling after file truncation leaves an orphaned intermediate node block that the log writer later processes via nilfs_direct_propagate, causing invalid virtual block number dereference outside the direct-mapping range.

Why it matters to the business

Local users on affected Linux systems using the nilfs2 file system can trigger kernel memory corruption leading to crashes, data loss, or potential privilege escalation; the 43-day-old issue remains unexploited in the wild with negligible EPSS and no KEV listing, limiting immediate operational urgency.

How an attack unfolds

An attacker with local access creates and truncates a file on a nilfs2 volume so that a B-tree node collapses into direct mapping without deleting the intermediate node; the dirty node remains in cache, the log writer later invokes the direct-propagate path on it, and the resulting out-of-bounds access corrupts kernel memory for denial-of-service or code execution.

How to fix it

Upgrade the Linux kernel to a version containing the nilfs_btree_discard fix and the deform flag change to bop_delete; rebuild and reboot with the patched kernel; avoid mounting untrusted nilfs2 volumes until updated.

How to confirm the fix worked

Confirm the running kernel contains the commit adding nilfs_btree_discard during mapping collapse; test by reproducing the truncation scenario under KASAN to verify absence of slab-out-of-bounds; inspect nilfs2 source for the deform flag handling in bop_delete.

Typical attack path

1. Obtain local shell or user context on a system mounting nilfs2
2. Create a file and perform truncation that collapses B-tree mapping
3. Trigger log writer activity that reuses the orphaned node block
4. nilfs_direct_propagate performs out-of-bounds slab access
5. Kernel memory corruption yields crash or escalation

How to detect it

Search kernel logs and dmesg for KASAN reports mentioning nilfs_direct_propagate or slab-out-of-bounds during nilfs2 truncation; look for repeated log-writer activity immediately after file truncation on nilfs2 volumes; no public IOCs or threat-actor artifacts are known.

What your security team should do

• Prioritize kernel updates on any systems actively using nilfs2
• Disable nilfs2 module or avoid mounting nilfs2 volumes if updates cannot be applied promptly
• Monitor kernel logs for KASAN or slab corruption messages referencing nilfs_direct_propagate
• Review EPSS trend remains flat; no immediate KEV or ransomware indicators