FKIE_CVE-2026-80734
Vulnerability from fkie_nvd - Published: 2026-09-03 13:06 - Updated: 2026-09-04 05:17
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
btrfs: initialize inode mapping flags for cached inodes
[BUG]
When running generic/795 with 8K block size, 4K page size, the test
always fails, triggering some ASSERT()s related to folio size:
795 (241074): drop_caches: 3
assertion failed: IS_ALIGNED(start, blocksize) && IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0)
------------[ cut here ]------------
kernel BUG at extent_io.c:1404!
Oops: invalid opcode: 0000 [#1] SMP
CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs]
Call Trace:
<TASK>
btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
iter_file_splice_write+0x31a/0x540
direct_splice_actor+0x53/0x170
splice_direct_to_actor+0xe9/0x240
do_splice_direct+0x76/0xb0
vfs_copy_file_range+0x1fd/0x630
__x64_sys_copy_file_range+0xf9/0x220
do_syscall_64+0xe1/0x790
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
---[ end trace 0000000000000000 ]---
The ASSERT() itself is added by a later patch.
The crash is triggered with that new debug patch, and without this fix.
[CAUSE]
In the above case, the start 16826368 is properly 8K aligned, but the
end (16830463 + 1) is not 8K aligned.
Furthermore the mapping's minimal folio order is 0, not the expected 1
for 8K block size with 4K page size.
So this means some inodes do not have btrfs_set_inode_mapping_order()
called on it.
The missing btrfs_set_inode_mapping_order() call happens for cached
inodes, through the following events:
- btrfs_create_new_inode() called for inode X
Which properly sets minimal folio order for the VFS inode.
- btrfs_update_inode() called for inode X
Which calls btrfs_delayed_update_inode() to create a delayed_node
into root->delayed_nodes xarray.
- Drop cache/memory pressure, evicting in-memory inode X
Which evicted the inode X, but delayed_node is still in
root->delayed_nodes for future reuse.
- btrfs_iget() for inode X called again
btrfs_iget()
|- btrfs_iget_locked()
| |- iget5_locked_rcu()
| Which creates a new vfs_inode for btrfs, whose mapping still
| has the minimal order as 0.
|
|- btrfs_read_locked_inode()
|- btrfs_fill_inode()
| |- btrfs_get_delayed_node()
| Which found out the previous node, and use that delayed
| node to initialize the new inode.
|
|- filled = true;
|- if (filled) goto cache_index;
Which skips the btrfs_update_inode_mapping_flags() and
btrfs_set_inode_mapping_order() calls.
So the inode still has minimal folio order set as 0, not
the required 1.
Thus later page cache read will get a folio whose size is smaller than
block size, as the mapping has its minimal folio order set as 0 not 1,
then trigger the ASSERT().
[FIX]
Move the btrfs_update_inode_mapping_flags() and
btrfs_set_inode_mapping_order() calls under cache_index label,
so that the mapping flags and minimal folio order is always set
no matter if we have a cached inode.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/btrfs/inode.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0d26249671171ab759cb4fdce673554a690fa655",
"status": "affected",
"version": "ecde48a1a6b3256bd49db8780bf37556b157783c",
"versionType": "git"
},
{
"lessThan": "0ef349734a93227b45f65fc50a3311d1cc5f03e9",
"status": "affected",
"version": "ecde48a1a6b3256bd49db8780bf37556b157783c",
"versionType": "git"
},
{
"status": "affected",
"version": "ae584726e6eddf6cfbe49b3f4a78b3197716b6f8",
"versionType": "git"
},
{
"lessThan": "6.15",
"status": "affected",
"version": "6.14.6",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/btrfs/inode.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.15"
},
{
"lessThan": "6.15",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.1.*",
"status": "unaffected",
"version": "7.1.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.2",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: initialize inode mapping flags for cached inodes\n\n[BUG]\nWhen running generic/795 with 8K block size, 4K page size, the test\nalways fails, triggering some ASSERT()s related to folio size:\n\n 795 (241074): drop_caches: 3\n assertion failed: IS_ALIGNED(start, blocksize) \u0026\u0026 IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0)\n ------------[ cut here ]------------\n kernel BUG at extent_io.c:1404!\n Oops: invalid opcode: 0000 [#1] SMP\n CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs]\n Call Trace:\n \u003cTASK\u003e\n btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]\n prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]\n btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]\n btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]\n iter_file_splice_write+0x31a/0x540\n direct_splice_actor+0x53/0x170\n splice_direct_to_actor+0xe9/0x240\n do_splice_direct+0x76/0xb0\n vfs_copy_file_range+0x1fd/0x630\n __x64_sys_copy_file_range+0xf9/0x220\n do_syscall_64+0xe1/0x790\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u003c/TASK\u003e\n ---[ end trace 0000000000000000 ]---\n\nThe ASSERT() itself is added by a later patch.\nThe crash is triggered with that new debug patch, and without this fix.\n\n[CAUSE]\nIn the above case, the start 16826368 is properly 8K aligned, but the\nend (16830463 + 1) is not 8K aligned.\nFurthermore the mapping\u0027s minimal folio order is 0, not the expected 1\nfor 8K block size with 4K page size.\n\nSo this means some inodes do not have btrfs_set_inode_mapping_order()\ncalled on it.\n\nThe missing btrfs_set_inode_mapping_order() call happens for cached\ninodes, through the following events:\n\n- btrfs_create_new_inode() called for inode X\n Which properly sets minimal folio order for the VFS inode.\n\n- btrfs_update_inode() called for inode X\n Which calls btrfs_delayed_update_inode() to create a delayed_node\n into root-\u003edelayed_nodes xarray.\n\n- Drop cache/memory pressure, evicting in-memory inode X\n Which evicted the inode X, but delayed_node is still in\n root-\u003edelayed_nodes for future reuse.\n\n- btrfs_iget() for inode X called again\n\n btrfs_iget()\n |- btrfs_iget_locked()\n | |- iget5_locked_rcu()\n | Which creates a new vfs_inode for btrfs, whose mapping still\n | has the minimal order as 0.\n |\n |- btrfs_read_locked_inode()\n |- btrfs_fill_inode()\n | |- btrfs_get_delayed_node()\n | Which found out the previous node, and use that delayed\n | node to initialize the new inode.\n |\n |- filled = true;\n |- if (filled) goto cache_index;\n Which skips the btrfs_update_inode_mapping_flags() and\n\tbtrfs_set_inode_mapping_order() calls.\n\tSo the inode still has minimal folio order set as 0, not\n\tthe required 1.\n\nThus later page cache read will get a folio whose size is smaller than\nblock size, as the mapping has its minimal folio order set as 0 not 1,\nthen trigger the ASSERT().\n\n[FIX]\nMove the btrfs_update_inode_mapping_flags() and\nbtrfs_set_inode_mapping_order() calls under cache_index label,\nso that the mapping flags and minimal folio order is always set\nno matter if we have a cached inode."
}
],
"id": "CVE-2026-80734",
"lastModified": "2026-09-04T05:17:13.900",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-09-03T13:06:12.200",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0d26249671171ab759cb4fdce673554a690fa655"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0ef349734a93227b45f65fc50a3311d1cc5f03e9"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…