CVE-2026-98049
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: zero extend the result of an arena 32-bit cmpxchg
bpf_convert_ctx_accesses() rewrites an atomic on an arena pointer from BPF_STX | BPF_ATOMIC to BPF_STX | BPF_PROBE_ATOMIC, and it runs before bpf_opt_subreg_zext_lo32_rnd_hi32().
That pass emits an explicit zero extension for a 32-bit cmpxchg even when bpf_jit_needs_zext() is false. This is done because on some architectures 32-bit cmpxchg requires explicit zero extension for the dst register. E.g. on x86-64 'lock cmpxchg' does not change the %eax if comparison is successful, while BPF semantics declare that each operation on a 32-bit register zero extends it's upper half.
is_cmpxchg_insn() matches BPF_MODE == BPF_ATOMIC only, so an arena cmpxchg misses said zero extension adjustment. This patch adjusts is_cmpxchg_insn() to match BPF_PROBE_ATOMIC alongside BPF_ATOMIC.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel contains a vulnerability within the Berkeley Packet Filter (BPF) subsystem related to improper handling of atomic compare-and-swap operations on arena pointers. Specifically, the function bpf_convert_ctx_accesses rewrites certain atomic instructions from standard BPF_STX | BPF_ATOMIC to BPF_STX | BPF_PROBE_ATOMIC. This transformation occurs prior to the execution of the optimization pass known as bpf_opt_subreg_zext_lo32_rnd_hi32, which is responsible for ensuring that 32-bit register operations are properly zero-extended in their upper 32 bits according to BPF semantics. On architectures such as x86-64, hardware instructions like lock cmpxchg do not automatically clear the upper half of the destination register upon a successful comparison and swap. However, the BPF virtual machine architecture mandates that any operation on a 32-bit register must result in zero extension of the upper 32 bits to maintain consistency and prevent data leakage or corruption from previous states.
The root cause of this vulnerability lies in the logic within is_cmpxchg_insn(), which determines whether an instruction requires explicit zero-extension adjustments during JIT compilation. Previously, this function only matched instructions with BPF_MODE set to BPF_ATOMIC. Consequently, when bpf_convert_ctx_accesses rewrites an arena pointer operation to use BPF_PROBE_ATOMIC, the subsequent optimization pass fails to recognize it as a cmpxchg instruction that needs adjustment. As a result, the upper 32 bits of the register remain unmodified after the atomic operation completes. This deviation from expected behavior means that stale data or sensitive information residing in the upper half of the register persists into subsequent operations, violating the architectural contract of BPF registers.
This flaw can lead to significant security and stability implications within eBPF programs running on affected kernels. Since the upper bits are not zeroed out, an attacker who controls part of the program logic or memory state could potentially exploit this inconsistency to leak kernel memory contents or manipulate control flow by relying on non-zero extended values in conditional branches or arithmetic operations that assume clean 32-bit inputs. This aligns with CWE-197, which describes numeric truncation errors where a larger type is improperly converted to a smaller one without proper handling of the remaining bits, and can also be viewed through the lens of CWE-665 regarding improper initialization if the uninitialized upper bits lead to unpredictable behavior in subsequent logic. From an ATT&CK perspective, this could facilitate lateral movement or privilege escalation by allowing eBPF programs to bypass certain sanitization checks that rely on strict register state assumptions.
The resolution involves updating is_cmpxchg_insn() to also match instructions with BPF_MODE set to BPF_PROBE_ATOMIC alongside the existing check for BPF_ATOMIC. This ensures that all arena-based atomic compare-and-swap operations undergo the necessary zero-extension adjustment during JIT compilation, thereby restoring compliance with BPF semantics across supported architectures like x86-64. To mitigate this issue in environments where kernel updates are not immediately feasible, administrators should restrict unprivileged eBPF program loading by enforcing strict access controls via LSM modules such as AppArmor or SELinux, and ensure that only trusted, verified programs are permitted to execute with elevated privileges. Additionally, monitoring for unusual eBPF JIT compilation patterns or unexpected register states in debugging sessions can help detect exploitation attempts of this flaw before it leads to broader system compromise.