CVE-2026-80807

What it actually does

Improper input validation in the nilfs2 GC ioctl permits crafted nilfs_vdesc structures with vd_offset or vd_vblocknr values that produce a page index of ULONG_MAX; the resulting folio inserted into the page cache triggers repeated detection by filemap_get_folios_tag inside nilfs_lookup_dirty_data_buffers, causing duplicate list_add_tail operations on bh->b_assoc_buffers and list corruption.

Why it matters to the business

Local users on systems using the nilfs2 filesystem can trigger a kernel crash or memory corruption, leading to denial of service; the low EPSS and absence from KEV indicate limited real-world exploitation risk at present, but unpatched kernels remain exposed until upstream fixes are backported.

How an attack unfolds

An attacker with local access crafts a malicious GC ioctl request containing out-of-range vd_offset and vd_vblocknr values that wrap to ULONG_MAX, causing the kernel to insert an invalid folio; subsequent dirty-buffer lookup operations then corrupt internal lists, resulting in a crash or potential further memory manipulation.

How to fix it

Apply the upstream patch that adds range checks on vd_offset and vd_vblocknr before page-cache insertion; rebuild and deploy a fixed kernel; until patches are available, avoid mounting untrusted nilfs2 volumes or restrict local access to the GC ioctl via LSM policies.

How to confirm the fix worked

Confirm the fix by inspecting the nilfs_lookup_dirty_data_buffers and nilfs_vdesc handling paths for explicit bounds checks on vd_offset and vd_vblocknr; test with a reproducer that previously produced ULONG_MAX indices and verify no list corruption occurs.

Typical attack path

1. Obtain local unprivileged access on a nilfs2-mounted system
2. Prepare a nilfs_vdesc structure with vd_offset/vd_vblocknr values chosen to produce page index ULONG_MAX
3. Invoke the nilfs2 GC ioctl with the crafted structure
4. Trigger filemap_get_folios_tag via normal or attacker-controlled I/O to induce duplicate list processing
5. Observe list corruption leading to kernel oops or panic

How to detect it

Review kernel logs for nilfs2 list corruption or double-add warnings, page-cache folio index anomalies, and oops traces originating from nilfs_lookup_dirty_data_buffers; correlate with processes invoking the GC ioctl.

What your security team should do

• Prioritize kernel updates containing the nilfs2 GC ioctl range check once released
• Monitor upstream nilfs2 commits and stable kernel branches for backports
• Restrict untrusted local users from mounting or performing GC operations on nilfs2 volumes where possible
• Include nilfs2-related list corruption signatures in kernel crash-dump triage playbooks