CVE-2026-93147 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/bpf: Replace ly instruction with llgf
cpu_nr is a 32 bit value and BPF_REG_0 is a 64 bit register, when ly loads the cpu_nr into BPF_REG_0 it does not zero the upper bits, but llgf does.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The identified vulnerability resides within the Linux kernel's eBPF (extended Berkeley Packet Filter) implementation for the s390 architecture, specifically concerning the handling of register operations during instruction translation. The core technical flaw involves an incorrect code generation sequence where a load-unsigned-byte immediate instruction is utilized instead of a load-and-give-full-register instruction when moving data into BPF_REG_0. This discrepancy arises from a mismatch between the source data width and the destination register width, leading to improper sign extension behavior that compromises the integrity of subsequent computations performed by eBPF programs.
In the s390 architecture, general-purpose registers are 64 bits wide, while certain kernel variables such as cpu_nr are defined as 32-bit values. When an eBPF program attempts to load a 32-bit value into BPF_REG_0, which is a full 64-bit register, the method used to perform this transfer dictates how the upper 32 bits of the destination register are populated. The original implementation employed the ly instruction, which loads only the lower byte or word depending on context but critically fails to zero out or properly sign-extend into the remaining high-order bits of the target register in all necessary scenarios for eBPF semantics. This results in BPF_REG_0 containing garbage data from previous operations in its upper half, effectively corrupting the value intended for use by the verifier and subsequent execution engine.
The operational impact of this vulnerability is significant because it violates the strict type safety guarantees enforced by the eBPF verifier. The Linux kernel's eBPF subsystem relies on precise tracking of register types to prevent out-of-bounds memory accesses, invalid pointer arithmetic, and other unsafe operations during program execution. If BPF_REG_0 contains uninitialized or stale high-order bits due to the ly instruction not zeroing them, the verifier may incorrectly classify the register type as signed rather than unsigned, or vice versa, leading to false positives in safety checks or, more dangerously, allowing programs that should be rejected to execute with undefined behavior. This can potentially lead to kernel crashes, privilege escalation if an attacker can exploit the resulting state corruption, or general system instability depending on how the corrupted register value is subsequently used within the eBPF program logic.
This issue aligns with CWE-697, which describes incorrect comparison of signed and unsigned values, as well as CWE-120, Buffer Copy without Checking Size of Input, in contexts where memory operations depend on potentially malformed or improperly extended registers. From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability falls under Tactic TA0004 Privilege Escalation and Technique T1068 Exploitation for Privilege Escalation, as an attacker could theoretically leverage improper register state to bypass security checks implemented by eBPF programs that monitor system calls or network traffic. The flaw represents a classic case of low-level architectural mismatch where the abstraction layer fails to enforce correct data width handling across different instruction sets.
To mitigate this vulnerability, it is essential to replace the ly instruction with llgf in the s390 BPF code generation path. The llgf instruction explicitly loads a 32-bit signed integer into a 64-bit register while simultaneously sign-extending the value and zeroing or properly handling the upper bits according to eBPF requirements for specific operations, ensuring that no residual high-order garbage remains in the destination register. This change ensures that BPF_REG_0 contains only the intended data with correct semantic meaning regarding its width and signedness. Developers maintaining the s390 architecture support within the Linux kernel must verify that all similar load operations adhere to these strict zero-extension or sign-extension rules mandated by the eBPF specification, thereby preserving the integrity of the verifier's type tracking system and preventing potential exploitation vectors arising from register state corruption.