Skip to main content

Linux Kernel CVE-2026-53092

| EUVDEUVD-2026-38960 HIGH
Return of Wrong Status Code (CWE-393)
2026-06-24 Linux GHSA-4p37-9v73-jm8h
Information Disclosure Linux
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.8 HIGH

Local attacker needs the low-privilege ability to load BPF (PR:L, AV:L); a successful verifier-bypass yields kernel memory read/write enabling full compromise (C/I/A:H), no UI required.

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

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

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

Lifecycle Timeline

4
Analysis Generated
Jun 28, 2026 - 09:10 vuln.today
CVSS changed
Jun 28, 2026 - 08:22 NVD
7.8 (HIGH)
CVE Published
Jun 24, 2026 - 16:30 cve.org
UNKNOWN (no severity yet)
CVE Published
Jun 24, 2026 - 16:30 cve.org
HIGH 7.8

DescriptionCVE.org

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

bpf: Fix linked reg delta tracking when src_reg == dst_reg

Consider the case of rX += rX where src_reg and dst_reg are pointers to the same bpf_reg_state in adjust_reg_min_max_vals(). The latter first modifies the dst_reg in-place, and later in the delta tracking, the subsequent is_reg_const(src_reg)/reg_const_value(src_reg) reads the post-{add,sub} value instead of the original source.

This is problematic since it sets an incorrect delta, which sync_linked_regs() then propagates to linked registers, thus creating a verifier-vs-runtime mismatch. Fix it by just skipping this corner case.

AnalysisAI

Privilege-relevant memory corruption in the Linux kernel eBPF verifier (introduced around v6.11) lets a local user with BPF-loading capability defeat the verifier's range tracking when a register adds to itself (rX += rX), because adjust_reg_min_max_vals() mutates dst_reg in place and then reads the already-modified src_reg, recording a wrong delta that sync_linked_regs() propagates to linked registers. The result is a verifier-vs-runtime mismatch - the verifier reasons about register bounds that differ from actual execution, the classic precursor to out-of-bounds kernel memory access and local privilege escalation. CVSS is 7.8 (High); EPSS is low (0.17%, 6th percentile), there is no public exploit identified at time of analysis, and it is not listed in CISA KEV.

Technical ContextAI

The flaw lives in the eBPF verifier, the in-kernel static analyzer that proves BPF programs are memory-safe before they are JIT-compiled and run. It tracks each register as a bpf_reg_state with min/max bounds and maintains links between registers that share a known scalar relationship (sync_linked_regs / 'linked reg delta tracking'). When src_reg and dst_reg point to the same bpf_reg_state - i.e. an instruction like rX += rX or rX -= rX - adjust_reg_min_max_vals() updates the destination in place, then the delta computation calls is_reg_const(src_reg)/reg_const_value(src_reg), which now returns the post-arithmetic value rather than the original operand. The recorded delta is therefore wrong and gets propagated to linked registers. The root cause is an aliasing/order-of-operations error (effectively a CWE-682 incorrect-calculation / CWE-787-adjacent unsafe state-tracking bug; the feed lists CWE as N/A). The fix simply detects and skips this src==dst corner case. CPE data only generically identifies cpe:2.3:a:linux:linux:*, i.e. the mainline kernel rather than a specific distro build.

RemediationAI

Upgrade to a fixed stable kernel - Vendor-released patch: 6.18.33, 7.0.10, or 7.1 (or your distribution's equivalent backport build) using stable commits d88e8e4a3b52bd5b2ff3eceba4b29d1b5506d066, cc86a8b0a1c54d2bccf6f68cf49b82dea91b84de, or d7f14173c0d5866c3cae759dee560ad1bed10d2e from https://git.kernel.org/stable/. If you cannot patch immediately, the most effective compensating control is to deny attackers the ability to load BPF programs: ensure unprivileged BPF is disabled by setting kernel.unprivileged_bpf_disabled=1 (sysctl), which blocks unprivileged users from reaching the verifier at the cost of breaking any workload that relies on unprivileged BPF (rare in production). Additionally, withhold CAP_BPF and CAP_SYS_ADMIN from untrusted users and containers and confine BPF loading via seccomp/LSM (e.g. SELinux/AppArmor bpf() restrictions) - the trade-off is that legitimate observability/networking agents (Cilium, bpftrace, systemd features) that load BPF will also be restricted and may need an allowlist. Validate fixes via the advisory at https://nvd.nist.gov/vuln/detail/CVE-2026-53092.

Same weakness CWE-393 – Return of Wrong Status Code

View all
CVE-2024-49117 HIGH
8.8
CVE-2025-5987 HIGH
8.1
CVE-2025-24531 MEDIUM
6.7
CVE-2020-5401 MEDIUM
5.3
CVE-2025-32414 MEDIUM POC
5.6

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: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

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

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