CVE-2026-98132 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: don't downgrade half-dead scalar zero spills to STACK_ZERO
states.c:__clean_func_state() can downgrade scalar zero spill to STACK_ZERO in the following case:
*(u64 *)(r10 - 8) = 0; ... checkpoint ... r1 = *(u32 *)(r10 - 4); ... no reads from r10-8 ...
Here 4 bytes at r10-8 are dead and verifier changes scalar spill to a combination: 0000pppp (p stands for poison). Such a change breaks precision propagation chains. All places that produce STACK_ZERO should call bpf_mark_chain_precision() for the zero source.
This patch fixes the bug in a simplest way possible: avoids converting stack spills of zero to STACK_ZERO. Two smarter approaches are possible: - do bpf_mark_chain_precision() from __clean_func_state() - check slot liveness information in check_stack_write_fixed_off()
I investigated both and the changes required are a bit tricky, hence go with a simple fix for the time being.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel's Berkeley Packet Filter (BPF) subsystem contains a verifier logic flaw within the function state management code that can lead to incorrect program verification outcomes. Specifically, in states.c under the __clean_func_state routine, there is an issue where scalar zero spills are incorrectly downgraded to STACK_ZERO status even when they should not be. This occurs during scenarios involving partial writes and subsequent reads from different offsets on the stack frame pointer r10. For instance, if a program performs a 64-bit write of zero at offset r10-8 followed by a checkpoint operation, and later executes a 32-bit read from r10-4 without any intervening reads from r10-8, the verifier incorrectly identifies the upper 32 bits of the original stack slot as dead. Consequently, it transforms the scalar spill into a combination representing zero in the high half and poison values in the low half. This transformation fundamentally breaks precision propagation chains within the BPF verifier's data flow analysis engine.
Precision propagation is critical for ensuring that the BPF program maintains accurate knowledge of variable states throughout execution. When this chain is broken due to improper handling of stack spills, the verifier may fail to detect potential security violations or incorrect assumptions about register values. This can result in programs being accepted by the verifier when they should be rejected, potentially allowing maliciously crafted eBPF programs to execute with unintended privileges or behaviors. The vulnerability stems from a failure to properly mark chain precision for zero sources whenever STACK_ZERO status is assigned. While more sophisticated fixes involving direct calls to bpf_mark_chain_precision within __clean_func_state or enhanced liveness checks in check_stack_write_fixed_off were considered, the implemented solution opts for simplicity by avoiding the conversion of stack spills of zero to STACK_ZERO altogether during this specific cleanup phase.
From a security perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-754 Incorrect Check or Condition because it involves flawed logic in validating program state transitions. In terms of MITRE ATT&CK for Enterprise, particularly the T1059 Execution category related to command and script interpreters, vulnerabilities in kernel-level filtering mechanisms like BPF can be exploited by attackers who have gained initial access to execute arbitrary code within restricted environments such as containers or network namespaces. By bypassing verifier checks through precision chain corruption, an attacker might escalate privileges or exfiltrate data from isolated processes that rely on strict eBPF program constraints for security enforcement.
Mitigation strategies primarily involve applying the kernel patch that addresses this specific logic error in states.c. System administrators and developers should ensure their Linux kernels are updated to versions where this fix is included, as unpatched systems remain susceptible to potential verification bypasses via crafted BPF programs. Additionally, organizations deploying eBPF-based security tools such as Falco or Cilium should verify that the underlying kernel version incorporates these corrections to maintain the integrity of runtime security policies. Continuous monitoring for anomalous eBPF program loads and regular auditing of kernel updates are recommended practices to minimize exposure to this class of vulnerabilities until all affected systems are patched.