Skip to content
Fencer Intel
medium 5.5

CVE-2024-41067 json

btrfs: scrub: handle RST lookup error correctly

published 2y ago modified 4mo ago also EUVD-2024-38865

cvss
5.5
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 9%
public exploits
0
none known

Summary

In the Linux kernel, the following vulnerability has been resolved:

btrfs: scrub: handle RST lookup error correctly

[BUG] When running btrfs/060 with forced RST feature, it would crash the following ASSERT() inside scrub_read_endio():

ASSERT(sector_nr < stripe->nr_sectors);

Before that, we would have tree dump from btrfs_get_raid_extent_offset(), as we failed to find the RST entry for the range.

[CAUSE] Inside scrub_submit_extent_sector_read() every time we allocated a new bbio we immediately called btrfs_map_block() to make sure there was some RST range covering the scrub target.

But if btrfs_map_block() fails, we immediately call endio for the bbio, while the bbio is newly allocated, it's completely empty.

Then inside scrub_read_endio(), we go through the bvecs to find the sector number (as bi_sector is no longer reliable if the bio is submitted to lower layers).

And since the bio is empty, such bvecs iteration would not find any sector matching the sector, and return sector_nr == stripe->nr_sectors, triggering the ASSERT().

[FIX] Instead of calling btrfs_map_block() after allocating a new bbio, call btrfs_map_block() first.

Since our only objective of calling btrfs_map_block() is only to update stripe_len, there is really no need to do that after btrfs_alloc_bio().

This new timing would avoid the problem of handling empty bbio completely, and in fact fixes a possible race window for the old code, where if the submission thread is the only owner of the pending_io, the scrub would never finish (since we didn't decrease the pending_io counter).

Although the root cause of RST lookup failure still needs to be addressed.

Patch / fix

  • Linux Linux 6.9.11, 6.10
  • linux Debian 14, Debian 13 6.9.11-1

debian advisories DEBIAN-CVE-2024-41067

  • linux Ubuntu 24.04 LTS 6.8.0-48.48
  • linux-aws Ubuntu 24.04 LTS 6.8.0-1018.20
  • linux-gcp Ubuntu 24.04 LTS 6.8.0-1017.19
  • linux-gke Ubuntu 24.04 LTS 6.8.0-1013.17
  • linux-ibm Ubuntu 24.04 LTS 6.8.0-1015.15
  • linux-azure Ubuntu 24.04 LTS 6.8.0-1017.20
  • linux-gkeop Ubuntu 24.04 LTS 6.8.0-1002.4
  • linux-raspi Ubuntu 24.04 LTS 6.8.0-1014.16

ubuntu advisories UBUNTU-CVE-2024-41067

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

Is CVE-2024-41067 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2024-41067 updated cvss 5.5

kernel: btrfs: scrub: handle RST lookup error correctly

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more
    affected: workaround, no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
2y ago

Exploit prediction

0.20% chance of exploitation in the next 30 days, higher than 9% of all scored CVEs (FIRST EPSS, 2026-11-11).

CVSS scores

assigned by version score vector
NVD 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.