CVE-2026-72111 in Linuxinfo

Summary

by MITRE • 08/15/2026

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

bpf: Reset register bounds before narrowing retval range in check_mem_access()

When the BPF verifier processes a context load of an LSM hook return value, it calls __mark_reg_s32_range() to narrow the register to the hook's valid range. However, __mark_reg_s32_range() intersects the new range with the register's existing bounds using max_t()/min_t() rather than replacing them.

If the destination register carries stale bounds from a prior instruction (e.g. BPF_MOV64_IMM), the intersection can produce a range narrower than reality. The verifier then believes it knows the register's exact value, while at runtime the actual hook return value is loaded, creating a verifier/runtime mismatch that can be used to bypass BPF memory safety checks.

The else branch already calls mark_reg_unknown() to reset register state before any narrowing. Apply the same reset in the is_retval path so stale bounds are cleared before __mark_reg_s32_range() intersects.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 08/15/2026

The vulnerability described represents a critical flaw in the Linux kernel's BPF (Berkeley Packet Filter) verifier implementation that undermines memory safety protections through improper register bound handling during context load operations. This issue specifically affects the processing of LSM (Linux Security Module) hook return values where the verifier attempts to narrow register ranges to valid hook value boundaries. The root cause lies in how the __mark_reg_s32_range() function processes existing register bounds, using intersection operations with max_t()/min_t() instead of complete replacement, which creates a dangerous discrepancy between verification and runtime behavior.

The technical flaw manifests when the BPF verifier encounters context loads from LSM hooks that return values. During this process, __mark_reg_s32_range() is called to constrain the register to the valid range of possible return values for the specific hook. However, when the destination register contains stale bounds from previous instructions such as BPF_MOV64_IMM operations, the intersection logic with max_t()/min_t() can produce significantly narrower ranges than what actually occurs at runtime. This creates a scenario where the verifier incorrectly concludes it knows the exact value of the register during compilation, while the actual execution loads a different value that may bypass memory safety checks that should have been enforced.

The operational impact of this vulnerability extends beyond simple memory corruption risks to encompass potential privilege escalation and security bypass opportunities within systems utilizing BPF programs. Attackers could exploit this mismatch between verifier assumptions and runtime behavior to craft malicious BPF programs that appear valid to the verifier but execute with different memory access patterns at runtime. The vulnerability particularly affects systems running LSM modules where BPF programs interact with security hooks, creating potential attack vectors for bypassing kernel security controls and executing unauthorized memory operations.

The fix implemented addresses this by ensuring register state is properly reset before range narrowing operations occur. Specifically, the solution mirrors an existing pattern already present in the else branch of the code which calls mark_reg_unknown() to clear stale register information before any narrowing takes place. This reset mechanism ensures that when processing the is_retval path, any previous bounds information from prior instructions is completely cleared before __mark_reg_s32_range() performs its intersection operations. This approach aligns with established security practices for maintaining verification accuracy and preventing stale state propagation that could lead to runtime verification mismatches.

This vulnerability classification aligns with CWE-129 and CWE-131 categories related to improper bounds checking and incorrect calculation of buffer or array sizes. The attack pattern follows ATT&CK techniques such as T1059.007 for system service execution and T1566 for phishing attacks that could leverage BPF-based security bypasses. The fix demonstrates proper defensive programming principles by ensuring state isolation between operations and preventing information leakage from previous processing steps that could compromise subsequent verification decisions.

The resolution maintains the existing security model while eliminating the specific race condition between verifier state and runtime execution that enabled this vulnerability. By enforcing complete register state reset before range narrowing, the implementation ensures that BPF programs undergo accurate verification regardless of prior instruction sequences, maintaining the integrity of kernel memory safety controls. This approach prevents attackers from exploiting register bound intersection logic to craft programs that appear valid during compilation but execute with different memory access patterns at runtime, thereby preserving the fundamental security guarantees provided by the BPF verifier system.

The mitigation strategy directly addresses a known weakness in kernel verification systems where state persistence between unrelated operations can create false positives in security checks. This class of vulnerability highlights the importance of maintaining clean state boundaries in complex verification systems and demonstrates how seemingly minor implementation details in kernel code can have significant security implications. The solution maintains backward compatibility while strengthening the security model through explicit state management practices that prevent stale information from influencing subsequent verification decisions.

Responsible

Linux

Reservation

08/09/2026

Disclosure

08/15/2026

Moderation

accepted

CPE

ready

EPSS

0.00210

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!