CVE-2026-80807nilfs2: reject invalid block index in GC ioctl
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 19, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 7942b919f7321f95a777d396ff7894a7a83dc9b0 before 898404cdf882d7b54f1132f75570984ca3214796; from 7942b919f7321f95a777d396ff7894a7a83dc9b0 before ba8a8b563a28d358c45c62a306d421434a058648; 7942b919f7321f95a777d396ff7894a7a83dc9b0 builds before 3bd064ccc70b85f9a3d53aece29dc8473be5a226; from 7942b919f7321f95a777d396ff7894a7a83dc9b0 before a5e776e2937581d67ec5b9b4d27b0f70d7baa6b1; 7942b919f7321f95a777d396ff7894a7a83dc9b0 builds before 68aa9ab6f8f2895713aa6ddf781463ed8ea5ba44; from 7942b919f7321f95a777d396ff7894a7a83dc9b0 before e447f7edb99bd00cec63d6f3049e2e5074946f71; from 7942b919f7321f95a777d396ff7894a7a83dc9b0 before ec6ddf271dfa4c7e3147bc2c8b2bad4315f316a1; from 7942b919f7321f95a777d396ff7894a7a83dc9b0 before fbcfb75c20d71a5b542ad4ac3b79d10b997c8152; and 1 more ranges | CNA record |
References
- https://git.kernel.org/stable/c/898404cdf882d7b54f1132f75570984ca3214796
- https://git.kernel.org/stable/c/ba8a8b563a28d358c45c62a306d421434a058648
- https://git.kernel.org/stable/c/3bd064ccc70b85f9a3d53aece29dc8473be5a226
- https://git.kernel.org/stable/c/a5e776e2937581d67ec5b9b4d27b0f70d7baa6b1
- https://git.kernel.org/stable/c/68aa9ab6f8f2895713aa6ddf781463ed8ea5ba44
- https://git.kernel.org/stable/c/e447f7edb99bd00cec63d6f3049e2e5074946f71
- https://git.kernel.org/stable/c/ec6ddf271dfa4c7e3147bc2c8b2bad4315f316a1
- https://git.kernel.org/stable/c/fbcfb75c20d71a5b542ad4ac3b79d10b997c8152
- https://git.kernel.org/stable/c/a1735eae55448bc79c2da6593455791e886f6ed8
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.