CVE-2026-99080

What it actually does

The vulnerability is a long-standing leak of xarray nodes associated with inodes that can be forced via madvise operations; the fix adds an xa_destroy() call inside clear_inode() to release excess nodes while cycling the i_pages lock.

Why it matters to the business

On Linux systems the leak can gradually exhaust kernel memory under workloads that create and destroy many inodes, leading to performance degradation, increased swapping, or eventual denial of service; because the issue is only two days old and has no known exploitation, immediate operational impact remains low but rises with uptime and inode churn.

How an attack unfolds

An attacker with local code execution repeatedly exercises inode creation and destruction paths while issuing madvise calls that trigger the leak, causing xarray nodes to accumulate until memory pressure becomes noticeable; the technique was previously documented and recently made reliable by syzbot-style fuzzing.

How to fix it

Upgrade to a Linux kernel that contains the referenced commit (the patch that adds xa_destroy() inside clear_inode()); rebuild and reboot all affected systems; where immediate patching is impossible, restrict untrusted local access and monitor memory consumption.

How to confirm the fix worked

Confirm the kernel source contains the clear_inode() change that invokes xa_destroy(); run regression tests that exercise inode teardown under madvise; observe that xarray node counts no longer grow unbounded after repeated inode operations.

Typical attack path

1. Obtain local unprivileged execution on a Linux host
2. Trigger high-frequency inode lifecycle operations (open/close, mmap, etc.)
3. Interleave madvise calls to force the xarray-node leak
4. Sustain the workload until kernel memory pressure or OOM conditions appear

How to detect it

Examine kernel logs and memory statistics for repeated xarray allocation growth without corresponding frees after inode teardown; correlate with processes that heavily use madvise or mmap; no public exploitation artifacts exist yet, so focus on behavioral memory-anomaly detection rather than known-bad signatures.

What your security team should do

• Prioritize kernel updates on any system reachable by untrusted local users within the next maintenance window
• Add memory-usage telemetry for xarray/inode caches to existing monitoring
• Review and tighten local access controls on multi-tenant or container hosts
• Re-test after patching to ensure the leak is closed under synthetic madvise workloads