ghsa-798v-p58f-mw7j
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't drop extent_map for free space inode on write error
While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache.
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
Call Trace:
This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range.
This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map.
Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range.
I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test.
{
"affected": [],
"aliases": [
"CVE-2024-26726"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:54Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don\u0027t drop extent_map for free space inode on write error\n\nWhile running the CI for an unrelated change I hit the following panic\nwith generic/648 on btrfs_holes_spacecache.\n\nassertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385\n------------[ cut here ]------------\nkernel BUG at fs/btrfs/extent_io.c:1385!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1\nRIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0\nCall Trace:\n \u003cTASK\u003e\n extent_write_cache_pages+0x2ac/0x8f0\n extent_writepages+0x87/0x110\n do_writepages+0xd5/0x1f0\n filemap_fdatawrite_wbc+0x63/0x90\n __filemap_fdatawrite_range+0x5c/0x80\n btrfs_fdatawrite_range+0x1f/0x50\n btrfs_write_out_cache+0x507/0x560\n btrfs_write_dirty_block_groups+0x32a/0x420\n commit_cowonly_roots+0x21b/0x290\n btrfs_commit_transaction+0x813/0x1360\n btrfs_sync_file+0x51a/0x640\n __x64_sys_fdatasync+0x52/0x90\n do_syscall_64+0x9c/0x190\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nThis happens because we fail to write out the free space cache in one\ninstance, come back around and attempt to write it again. However on\nthe second pass through we go to call btrfs_get_extent() on the inode to\nget the extent mapping. Because this is a new block group, and with the\nfree space inode we always search the commit root to avoid deadlocking\nwith the tree, we find nothing and return a EXTENT_MAP_HOLE for the\nrequested range.\n\nThis happens because the first time we try to write the space cache out\nwe hit an error, and on an error we drop the extent mapping. This is\nnormal for normal files, but the free space cache inode is special. We\nalways expect the extent map to be correct. Thus the second time\nthrough we end up with a bogus extent map.\n\nSince we\u0027re deprecating this feature, the most straightforward way to\nfix this is to simply skip dropping the extent map range for this failed\nrange.\n\nI shortened the test by using error injection to stress the area to make\nit easier to reproduce. With this patch in place we no longer panic\nwith my error injection test.",
"id": "GHSA-798v-p58f-mw7j",
"modified": "2024-04-03T15:30:43Z",
"published": "2024-04-03T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26726"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e"
}
],
"schema_version": "1.4.0",
"severity": []
}
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.