CVE-2026-80807

nilfs2: reject invalid block index in GC ioctl

N/A
Published: September 4, 2026 at 03:13 PM UTC
Updated: October 19, 2026 at 09:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

2.6.307942b919f7321f95a777d396ff7894a7a83dc9b0
Vendor states this is fixed in 3bd064ccc70b85f9a3d53aece29dc8473be5a226 (fixed)
Vendor states this is fixed in 68aa9ab6f8f2895713aa6ddf781463ed8ea5ba44 (fixed)
Vendor states this is fixed in 898404cdf882d7b54f1132f75570984ca3214796 (fixed)
Vendor states this is fixed in a1735eae55448bc79c2da6593455791e886f6ed8 (fixed)
Vendor states this is fixed in a5e776e2937581d67ec5b9b4d27b0f70d7baa6b1 (fixed)
Vendor states this is fixed in ba8a8b563a28d358c45c62a306d421434a058648 (fixed)
Vendor states this is fixed in e447f7edb99bd00cec63d6f3049e2e5074946f71 (fixed)
Vendor states this is fixed in ec6ddf271dfa4c7e3147bc2c8b2bad4315f316a1 (fixed)
Vendor states this is fixed in fbcfb75c20d71a5b542ad4ac3b79d10b997c8152 (fixed)
Vendor states this is fixed in 2.6.30 (unaffected)
Vendor states this is fixed in 5.10.269 (unaffected)
Vendor states this is fixed in 5.15.220 (unaffected)
Vendor states this is fixed in 6.1.187 (unaffected)
Vendor states this is fixed in 6.12.108 (unaffected)
Vendor states this is fixed in 6.18.47 (unaffected)
Vendor states this is fixed in 6.6.156 (unaffected)
Vendor states this is fixed in 7.1.11 (unaffected)
Vendor states this is fixed in 7.2.1 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card