CVE-2026-90262: btrfs: retry verity reads for not-uptodate Merkle folios
In the Linux kernel, the following vulnerability has been resolved:
btrfs: retry verity reads for not-uptodate Merkle folios
btrfsreadmerkletreepage() can find a folio in the mapping that is not uptodate. After taking the folio lock, the current code treats that state as a read error and returns -EIO.
That can make a previous transient read failure sticky. If the failed read left a not-uptodate folio in the mapping, later callers find that folio and fail instead of retrying the read.
Keep the existing page-cache insertion and locking order, but retry the Merkle item read when a not-uptodate folio is found in the mapping. Also unlock the folio when readkeybytes() fails so that a later caller can lock it and retry the read.
Event History
Frequently Asked Questions
What systems are realistically exposed to this issue?
Systems using the Linux kernel with btrfs filesystem verity reads are affected by the described failure mode. The issue concerns reads of Merkle-tree data associated with verity-protected content on btrfs.
What conditions trigger the failure?
A transient read failure must leave a Merkle folio in the page-cache mapping without the uptodate state. A later caller that finds that folio can receive -EIO instead of causing the read to be retried.
What happens if reading key bytes fails?
The described vulnerable behavior can leave the folio locked when read_key_bytes() fails. This prevents a later caller from locking the folio and retrying the read.
What is the relevant remediation?
Apply a kernel update containing the referenced stable commits. The fix retries Merkle item reads for non-uptodate folios and unlocks the folio when read_key_bytes() fails, allowing subsequent retry attempts.