Answer in brief
CVE-2026-31666 records a High severity (CVSS 7.8) vulnerability in btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1618aa3c2e0163f5ac34d514ae89474521910536 <4125a194db4a6cf91f619f38788272651cb97dce || >=1618aa3c2e0163f5ac34d514ae89474521910536 <450e6a685d0cad95b15f8af152057bd0bf79f50b || >=1618aa3c2e0163f5ac34d514ae89474521910536 <ab1e022379c3c811aa72da8eb0c7507859a1d0f5 || >=1618aa3c2e0163f5ac34d514ae89474521910536 <316fb1b3169efb081d2db910cbbfef445afa03b9 | 4125a194db4a6cf91f619f38788272651cb97dce, 450e6a685d0cad95b15f8af152057bd0bf79f50b, ab1e022379c3c811aa72da8eb0c7507859a1d0f5, 316fb1b3169efb081d2db910cbbfef445afa03b9 |
| Linux/Linuxgeneric | 6.10 | Not reported |
Published upstream
Apr 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 16, 2026
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref() After commit 1618aa3c2e01 ("btrfs: simplify return variables in lookup_extent_data_ref()"), the err and ret variables were merged into a single ret variable. However, when btrfs_next_leaf() returns 0 (success), ret is overwritten from -ENOENT to 0. If the first key in the next leaf does not match (different objectid or type), the function returns 0 instead of -ENOENT, making the caller believe the lookup succeeded when it did not. This can lead to operations on the wrong extent tree item, potentially causing extent tree corruption. Fix this by returning -ENOENT directly when the key does not match, instead of relying on the ret variable.
Quoted source text, attributed separately from HOL analysis.