{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-80734", "modified": "2026-10-12T04:30:01Z", "upstream": [ "CVE-2026-80734" ], "published": "2026-09-03T08:22:05Z", "summary": "btrfs: initialize inode mapping flags for cached inodes", "details": "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) && 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 \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 \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's 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->delayed_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->delayed_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.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.29-1+rpt1", "1:6.18.33-1+rpt1", "1:6.18.34-1+rpt1", "1:6.18.39-1+rpt1", "1:6.18.50-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.29+rpt-rpi-2712", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v6", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v7", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v6", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v7", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-2712", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v6", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v7", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-2712", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v6", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v7", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8-rt", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-2712", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v6", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v7", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8-rt", "binary_version": "1:6.18.50-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.29-1+rpt1": { "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc", "upstream_version": "6.18.29", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.56" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.56" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.56" }, "1:6.18.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.56" }, "1:6.18.50-1+rpt1": { "linux_commit": "cff533aec2fa601846766b32ff57204e0a61bed7", "upstream_version": "6.18.50", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.56" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-80734" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e18b8236c57fcc67d793bfc866f4bb2581be9f72" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0d26249671171ab759cb4fdce673554a690fa655" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0ef349734a93227b45f65fc50a3311d1cc5f03e9" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-10-11T13:52:13Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.8, "cvss_v3_severity": "High", "scenario": "AV:N - The fault is reached from vfs_copy_file_range/splice buffered-write paths on btrfs inodes (as in the xfstest repro); on NFS-exported btrfs volumes remote clients can drive the same VFS copy_file_range path via nfsd NFSv4 COPY, making this network-reachable on NAS deployments.\nAC:L - Once a btrfs volume uses CONFIG_BTRFS_EXPERIMENTAL blocksize>pagesize, an attacker can deterministically create the delayed-node/evict/re-iget sequence with ordinary writes plus memory pressure (xfstest generic/795 reproduces reliably) without uncontrollable races or layout luck.\nPR:L - Triggering requires only write access to files on a mounted btrfs filesystem (or an authenticated NFS/SMB client with export write permission); no init-namespace root or non-namespace capabilities are needed beyond normal filesystem access.\nUI:N - No victim interaction is required; the attacker issues their own copy_file_range/write/splice syscalls (or remote COPY) after creating the inode state, without needing another user to mount, open, or click anything.\nS:U - Impact is confined to incorrect btrfs page-cache I/O and filesystem data/kernel stability on the host; it does not cross VM, container, IOMMU, or other security-authority boundaries.\nC:H - Skipping btrfs_set_inode_mapping_order leaves 4K folios on 8K-sector volumes, so read paths operate on block-misaligned ranges and can return stale adjacent on-disk sectors into attacker buffers, disclosing other users' btrfs file content on shared volumes.\nI:H - Wrong mapping min folio order and stable-writes flags break btrfs block-aligned buffered I/O invariants, allowing misaligned writes/checksum-unsafe writeback that can persist corrupted data and violate CoW/checksum integrity on the affected volume.\nA:H - The bug provokes kernel BUG/oops via assert_folio_range on misaligned folio ranges (documented in the fix commit), and blocks_per_folio becomes zero when folio_size