Description

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

btrfs: adjust subpage bit start based on sectorsize

When running machines with 64k page size and a 16k nodesize we started
seeing tree log corruption in production. This turned out to be because
we were not writing out dirty blocks sometimes, so this in fact affects
all metadata writes.

When writing out a subpage EB we scan the subpage bitmap for a dirty
range. If the range isn't dirty we do

bit_start++;

to move onto the next bit. The problem is the bitmap is based on the
number of sectors that an EB has. So in this case, we have a 64k
pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4
bits for every node. With a 64k page size we end up with 4 nodes per
page.

To make this easier this is how everything looks

[0 16k 32k 48k ] logical address
[0 4 8 12 ] radix tree offset
[ 64k page ] folio
[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers
[ | | | | | | | | | | | | | | | | ] bitmap

Now we use all of our addressing based on fs_info->sectorsize_bits, so
as you can see the above our 16k eb->start turns into radix entry 4.

When we find a dirty range for our eb, we correctly do bit_start +=
sectors_per_node, because if we start at bit 0, the next bit for the
next eb is 4, to correspond to eb->start 16k.

However if our range is clean, we will do bit_start++, which will now
put us offset ...

Classification

CVE ID: CVE-2025-37931

Affected Products

Vendor: Linux

Product: Linux

Exploit Prediction Scoring System (EPSS)

EPSS Score: 0.02% (probability of being exploited)

EPSS Percentile: 4.26% (scored less or equal to compared to others)

EPSS Date: 2025-06-18 (when was this score calculated)

References

https://nvd.nist.gov/vuln/detail/CVE-2025-37931
https://git.kernel.org/stable/c/b80db09b614cb7edec5bada1bc7c7b0eb3b453ea
https://git.kernel.org/stable/c/396f4002710030ea1cfd4c789ebaf0a6969ab34f
https://git.kernel.org/stable/c/e08e49d986f82c30f42ad0ed43ebbede1e1e3739

Timeline