{"id":"CVE-2024-41067","state":"PUBLISHED","title":"btrfs: scrub: handle RST lookup error correctly","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: scrub: handle RST lookup error correctly\n\n[BUG]\nWhen running btrfs/060 with forced RST feature, it would crash the\nfollowing ASSERT() inside scrub_read_endio():\n\n\tASSERT(sector_nr < stripe->nr_sectors);\n\nBefore that, we would have tree dump from\nbtrfs_get_raid_extent_offset(), as we failed to find the RST entry for\nthe range.\n\n[CAUSE]\nInside scrub_submit_extent_sector_read() every time we allocated a new\nbbio we immediately called btrfs_map_block() to make sure there was some\nRST range covering the scrub target.\n\nBut if btrfs_map_block() fails, we immediately call endio for the bbio,\nwhile the bbio is newly allocated, it's completely empty.\n\nThen inside scrub_read_endio(), we go through the bvecs to find\nthe sector number (as bi_sector is no longer reliable if the bio is\nsubmitted to lower layers).\n\nAnd since the bio is empty, such bvecs iteration would not find any\nsector matching the sector, and return sector_nr == stripe->nr_sectors,\ntriggering the ASSERT().\n\n[FIX]\nInstead of calling btrfs_map_block() after allocating a new bbio, call\nbtrfs_map_block() first.\n\nSince our only objective of calling btrfs_map_block() is only to update\nstripe_len, there is really no need to do that after btrfs_alloc_bio().\n\nThis new timing would avoid the problem of handling empty bbio\ncompletely, and in fact fixes a possible race window for the old code,\nwhere if the submission thread is the only owner of the pending_io, the\nscrub would never finish (since we didn't decrease the pending_io\ncounter).\n\nAlthough the root cause of RST lookup failure still needs to be\naddressed.","publishedAt":"2024-07-29T14:57:28.543Z","updatedAt":"2026-05-11T20:25:33.970Z","severity":null,"assigner":"Linux","products":["Linux Linux"],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"9acaa64187f9b4cbb75622883c96ea1a893d5431","status":"affected","lessThan":"17d1fd302a53d7e456a7412da74be74a0cf63a72","versionType":"git"},{"version":"9acaa64187f9b4cbb75622883c96ea1a893d5431","status":"affected","lessThan":"2c49908634a2b97b1c3abe0589be2739ac5e7fd5","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/btrfs/scrub.c"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"6.7","status":"affected"},{"version":"0","status":"unaffected","lessThan":"6.7","versionType":"semver"},{"version":"6.9.11","status":"unaffected","lessThanOrEqual":"6.9.*","versionType":"semver"},{"version":"6.10","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/btrfs/scrub.c"]}],"references":["https://git.kernel.org/stable/c/17d1fd302a53d7e456a7412da74be74a0cf63a72","https://git.kernel.org/stable/c/2c49908634a2b97b1c3abe0589be2739ac5e7fd5"],"weaknesses":[],"ingestedAt":"2026-10-29T20:07:39.287Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2024/41xxx/CVE-2024-41067.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2024-41067","state":"PUBLISHED","datePublished":"2024-07-29T14:57:28.543Z","dateUpdated":"2026-05-11T20:25:33.970Z","assignerShortName":"Linux","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateReserved":"2024-07-12T12:17:45.630Z"},"containers":{"cna":{"title":"btrfs: scrub: handle RST lookup error correctly","descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: scrub: handle RST lookup error correctly\n\n[BUG]\nWhen running btrfs/060 with forced RST feature, it would crash the\nfollowing ASSERT() inside scrub_read_endio():\n\n\tASSERT(sector_nr < stripe->nr_sectors);\n\nBefore that, we would have tree dump from\nbtrfs_get_raid_extent_offset(), as we failed to find the RST entry for\nthe range.\n\n[CAUSE]\nInside scrub_submit_extent_sector_read() every time we allocated a new\nbbio we immediately called btrfs_map_block() to make sure there was some\nRST range covering the scrub target.\n\nBut if btrfs_map_block() fails, we immediately call endio for the bbio,\nwhile the bbio is newly allocated, it's completely empty.\n\nThen inside scrub_read_endio(), we go through the bvecs to find\nthe sector number (as bi_sector is no longer reliable if the bio is\nsubmitted to lower layers).\n\nAnd since the bio is empty, such bvecs iteration would not find any\nsector matching the sector, and return sector_nr == stripe->nr_sectors,\ntriggering the ASSERT().\n\n[FIX]\nInstead of calling btrfs_map_block() after allocating a new bbio, call\nbtrfs_map_block() first.\n\nSince our only objective of calling btrfs_map_block() is only to update\nstripe_len, there is really no need to do that after btrfs_alloc_bio().\n\nThis new timing would avoid the problem of handling empty bbio\ncompletely, and in fact fixes a possible race window for the old code,\nwhere if the submission thread is the only owner of the pending_io, the\nscrub would never finish (since we didn't decrease the pending_io\ncounter).\n\nAlthough the root cause of RST lookup failure still needs to be\naddressed."}],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"9acaa64187f9b4cbb75622883c96ea1a893d5431","status":"affected","lessThan":"17d1fd302a53d7e456a7412da74be74a0cf63a72","versionType":"git"},{"version":"9acaa64187f9b4cbb75622883c96ea1a893d5431","status":"affected","lessThan":"2c49908634a2b97b1c3abe0589be2739ac5e7fd5","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/btrfs/scrub.c"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"6.7","status":"affected"},{"version":"0","status":"unaffected","lessThan":"6.7","versionType":"semver"},{"version":"6.9.11","status":"unaffected","lessThanOrEqual":"6.9.*","versionType":"semver"},{"version":"6.10","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["fs/btrfs/scrub.c"]}],"references":[{"url":"https://git.kernel.org/stable/c/17d1fd302a53d7e456a7412da74be74a0cf63a72"},{"url":"https://git.kernel.org/stable/c/2c49908634a2b97b1c3abe0589be2739ac5e7fd5"}],"providerMetadata":{"shortName":"Linux","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateUpdated":"2026-05-11T20:25:33.970Z"},"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.7","versionEndExcluding":"6.9.11"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.7","versionEndExcluding":"6.10"}]}]}],"x_generator":{"engine":"bippy-1.2.0"}},"adp":[{"title":"CVE Program Container","references":[{"url":"https://git.kernel.org/stable/c/17d1fd302a53d7e456a7412da74be74a0cf63a72","tags":["x_transferred"]},{"url":"https://git.kernel.org/stable/c/2c49908634a2b97b1c3abe0589be2739ac5e7fd5","tags":["x_transferred"]}],"providerMetadata":{"shortName":"CVE","orgId":"af854a3a-2127-422b-91ae-364da2661108","dateUpdated":"2024-08-02T04:46:52.378Z"}},{"title":"CISA ADP Vulnrichment","metrics":[{"other":{"type":"ssvc","content":{"id":"CVE-2024-41067","role":"CISA Coordinator","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"version":"2.0.3","timestamp":"2024-09-10T16:21:49.560093Z"}}}],"providerMetadata":{"shortName":"CISA-ADP","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","dateUpdated":"2024-09-11T17:34:00.426Z"}}]}}}