Skip to main content

Linux Kernel CVE-2026-31666

| EUVDEUVD-2026-25559 HIGH
2026-04-24 Linux GHSA-7wrc-m37g-996x
Information Disclosure Linux
7.8
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
6.3 MEDIUM

Local privileged access needed (AV:L/PR:L); triggering depends on specific on-disk leaf layout so AC:H; corruption harms integrity and availability but no confidentiality leak, so C:N.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

6
Analysis Generated
Jul 24, 2026 - 02:25 vuln.today
Patch released
Apr 27, 2026 - 20:00 nvd
Patch available
CVSS changed
Apr 27, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Apr 24, 2026 - 16:16 EUVD
EUVD ID Assigned
Apr 24, 2026 - 15:00 euvd
EUVD-2026-25559
CVE Published
Apr 24, 2026 - 14:45 nvd
HIGH 7.8

DescriptionCVE.org

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.

AnalysisAI

Local privilege-level extent tree corruption in the Linux kernel's Btrfs filesystem (versions 6.10 through the 6.18/6.19/7.0 development lines) arises because lookup_extent_data_ref() returns 0 (success) instead of -ENOENT after crossing to a new leaf whose first key does not match, causing callers to operate on the wrong extent tree item. There is no public exploit identified at time of analysis, and the EPSS score is very low (0.02%), indicating negligible likelihood of opportunistic exploitation; this is a reliability/data-integrity defect rather than a remotely reachable RCE. CVSS 7.8 (AV:L/PR:L) reflects local access requirements, not network exposure.

Technical ContextAI

The flaw lives in Btrfs, the copy-on-write filesystem shipped in the mainline Linux kernel. lookup_extent_data_ref() walks the extent tree to find a data reference; when the search runs off the end of a leaf, btrfs_next_leaf() is called to advance to the next leaf. Regression commit 1618aa3c2e01 ('btrfs: simplify return variables in lookup_extent_data_ref()') merged the separate err and ret variables into a single ret. As a result, a successful btrfs_next_leaf() return of 0 overwrites the intended -ENOENT sentinel, so a non-matching first key in the next leaf is misreported as a successful lookup. The affected CPE is cpe:2.3:a:linux:linux (mainline kernel). No CWE is assigned in the input, but this is functionally an incorrect return value / improper error handling defect (CWE-393-class: return of wrong status code) leading to logic operating on unintended on-disk metadata.

RemediationAI

Upgrade to a fixed kernel: Vendor-released patch versions 6.12.82, 6.18.23, 6.19.13, or 7.0 (or later) contain the fix, which restores an explicit -ENOENT return when the next-leaf key does not match. The corresponding upstream stable commits are 4125a194db4a6cf91f619f38788272651cb97dce, 450e6a685d0cad95b15f8af152057bd0bf79f50b, ab1e022379c3c811aa72da8eb0c7507859a1d0f5, and 316fb1b3169efb081d2db910cbbfef445afa03b9 (see https://git.kernel.org/stable/c/4125a194db4a6cf91f619f38788272651cb97dce). Apply your distribution's kernel update once Red Hat or SUSE ships the backport. There is no clean feature-level workaround since the bug is in core extent-tree lookup logic; if patching must be deferred on a critical system, the only meaningful compensating control is to avoid running Btrfs for new/critical volumes (e.g., use another filesystem) and to maintain verified backups plus periodic btrfs scrub to detect corruption early - noting that scrub detects but does not prevent the wrong-item operations, and switching filesystems is disruptive and not always feasible.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-31666 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy