Description
In the Linux kernel, the following vulnerability has been resolved:

nilfs2: reject invalid block index in GC ioctl

Syzbot reported list corruption caused by a double list_add_tail() call on
bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers().

Analysis revealed that the root cause was the insertion of a page/folio
with a page index of ULONG_MAX into the page cache via the GC ioctl.
filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(),
repeatedly detects a dirty folio with a page index of ULONG_MAX due to
index wrap-around, leading to duplicate processing of dirty buffers.

As a preparatory step, the GC ioctl loads the page/folio of the block to
be moved during GC and inserts it into the page cache based on information
in the nilfs_vdesc structure passed as an argument. Normally, this does
not cause issues because the user-space GC library configures the
nilfs_vdesc structure properly. However, since there is no range check on
the parameters determining the page index, a request with artificially
crafted parameters -- such as those generated by Syzbot -- can result in a
page/folio being inserted with a page index of ULONG_MAX, triggering the
above problem.

This resolves the issue by checking the ranges of 'vd_offset' and
'vd_vblocknr' in the nilfs_vdesc structure that determine the page index,
thereby preventing the invalid page/folio insertions.
Published: 2026-09-04
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

This vulnerability arises from an absent bounds check on the nilfs2 GC ioctl arguments, allowing a crafted request to insert a page with the maximum unsigned long index into the page cache. The resulting double list_add_tail on bh->b_assoc_buffers inside nilfs_lookup_dirty_data_buffers corrupts the kernel’s dirty buffer tracking list, potentially causing further kernel memory corruption and application crashes. The corruption enables an attacker to destabilize the system and potentially gain elevated privileges.

Affected Systems

All Linux kernels that build the nilfs2 file system are potentially affected. The description does not specify affected release versions, so any instance that includes nilfs2 without the range‑check patch may be vulnerable. It is inferred that any configuration exposing the nilfs2 GC ioctl is potentially vulnerable.

Risk and Exploitability

Exploitation requires a local user to invoke the nilfs2 GC ioctl with carefully crafted parameters. No remote code execution mechanism is reported, and the vulnerability does not require network access. The EPSS score is not available and the issue is not listed in the CISA KEV catalog. Because the flaw can corrupt kernel memory structures, the overall risk is significant for any system where the nilfs2 GC ioctl is accessible to untrusted users.

Generated by OpenCVE AI on September 4, 2026 at 22:00 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the nilfs2 range‑check patch
  • Apply the kernel patch that enforces bounds validation on vd_offset and vd_vblocknr before inserting a page/folio into the page cache
  • Restrict access to the nilfs2 GC ioctl to a trusted privileged group or remove the capability from untrusted users
  • Monitor kernel logs for signs of repeated list_add_tail failures or page‑cache anomalies that may indicate exploitation attempts

Generated by OpenCVE AI on September 4, 2026 at 22:00 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 04 Sep 2026 22:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20

Fri, 04 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.
Title nilfs2: reject invalid block index in GC ioctl
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-04T15:13:23.605Z

Reserved: 2026-08-26T14:34:25.794Z

Link: CVE-2026-80807

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-04T16:18:07.810

Modified: 2026-09-04T16:18:07.810

Link: CVE-2026-80807

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-04T22:00:06Z

Weaknesses
  • CWE-20

    Improper Input Validation