{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-35798", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-35798" ], "published": "2024-05-17T13:23:58Z", "summary": "btrfs: fix race in read_extent_buffer_pages()", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race in read_extent_buffer_pages()\n\nThere are reports from tree-checker that detects corrupted nodes,\nwithout any obvious pattern so possibly an overwrite in memory.\nAfter some debugging it turns out there's a race when reading an extent\nbuffer the uptodate status can be missed.\n\nTo prevent concurrent reads for the same extent buffer,\nread_extent_buffer_pages() performs these checks:\n\n /* (1) */\n if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags))\n return 0;\n\n /* (2) */\n if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags))\n goto done;\n\nAt this point, it seems safe to start the actual read operation. Once\nthat completes, end_bbio_meta_read() does\n\n /* (3) */\n set_extent_buffer_uptodate(eb);\n\n /* (4) */\n clear_bit(EXTENT_BUFFER_READING, &eb->bflags);\n\nNormally, this is enough to ensure only one read happens, and all other\ncallers wait for it to finish before returning. Unfortunately, there is\na racey interleaving:\n\n Thread A | Thread B | Thread C\n ---------+----------+---------\n (1) | |\n | (1) |\n (2) | |\n (3) | |\n (4) | |\n | (2) |\n | | (1)\n\nWhen this happens, thread B kicks of an unnecessary read. Worse, thread\nC will see UPTODATE set and return immediately, while the read from\nthread B is still in progress. This race could result in tree-checker\nerrors like this as the extent buffer is concurrently modified:\n\n BTRFS critical (device dm-0): corrupted node, root=256\n block=8550954455682405139 owner mismatch, have 11858205567642294356\n expect [256, 18446744073709551360]\n\nFix it by testing UPTODATE again after setting the READING bit, and if\nit's been set, skip the unnecessary read.\n\n[ minor update of changelog ]", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.6.20-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v6", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.24" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-35798" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable code is reached through ordinary filesystem syscalls (open/stat/read/readdir/write) against a locally mounted btrfs filesystem. No network protocol handler is involved, so this requires local system access.\nAC:L - The attacker controls every side of the race \u2014 multiple threads performing concurrent lookups of the same cold metadata block, with readahead supplying the WAIT_NONE submitter \u2014 and can retry indefinitely while adding memory and CPU pressure to widen the window. The race is known to trigger spontaneously in production without any attacker.\nPR:L - Any unprivileged local user with read access to a mounted btrfs filesystem can drive concurrent metadata reads of the same extent buffer; btrfs is the default root filesystem on several major distributions. No capability, ioctl, mount privilege, or namespace trick is needed.\nUI:N - The attacker triggers the race entirely with its own file I/O against an already-mounted filesystem. No victim action or cooperation is required.\nS:U - The corruption occurs within kernel memory and on-disk metadata managed by the same kernel security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - Threads consume extent-buffer contents while DMA concurrently overwrites them, yielding torn header/item fields; garbage node blockptrs and nritems drive reads of arbitrary logical addresses, and the resulting heap out-of-bounds access on struct btrfs_path is leverageable for kernel memory disclosure.\nI:H - btrfs_search_slot() writes p->nodes[level] and p->slots[level] with an unvalidated 8-bit level taken from the racing memory, giving an out-of-bounds write of a kernel pointer past a kmalloc'd btrfs_path; separately, a leaf modified under an in-flight overwrite is checksummed and written back, causing persistent on-disk metadata corruption.\nA:H - The documented outcome is tree-checker \"corrupted node\" reports leading to -EUCLEAN and transaction abort with the filesystem forced read-only, and the out-of-bounds writes and garbage tree traversal readily produce ASSERT/BUG_ON hits and kernel oopses." } } }