CVE-2026-98590 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpf_sock context code generation
Currently, the ctx access code reads the rx_queue_mapping field with either a 4-byte or 2-byte load. The rest of the bits in the register are marked known zero by the verifier. However, the emitted ctx access code places in the register on certain the special value (-1) using BPF_MOV_IMM64, which gets sign-extended to turn on all the bits in the register. By shifting this value right, the program ends up with a value at runtime above what the verifier assumes is possible.
Fix this by ensuring the read value is as wide as the assumed size. Use MOV32 instructions instead of MOV64 instructions to keep the upper bits zero as assumed by the verifier. Also properly report the size of the destination variable (the bpf_sock field, 4 bytes) instead of the source (the socket field, 2 bytes).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel's Berkeley Packet Filter subsystem contains a critical code generation flaw within the handling of BPF sock context structures. This vulnerability arises from an inconsistency between how the verifier analyzes register states and how the JIT compiler or interpreter emits machine instructions for accessing specific fields, specifically the rx_queue_mapping field. The core issue lies in the width of data loads performed during runtime execution versus the assumptions made by the static analysis engine. When the kernel attempts to read this context field, it may utilize either a 4-byte or a 2-byte load operation depending on internal logic paths. In both scenarios, the verifier correctly identifies that only the lower portion of the register contains valid data and marks all upper bits as known zero. This assumption is fundamental for subsequent security checks performed by the BPF verifier to prevent out-of-bounds memory access and other unsafe operations.
The technical flaw manifests when the emitted code uses a 64-bit move immediate instruction, specifically BPF_MOV_IMM64, to place a special value of negative one into the register before shifting it right. Because this is a full 64-bit operation, the value -1 undergoes sign extension, resulting in all bits in the upper half of the register being set to one. This runtime behavior directly contradicts the verifier's static analysis which expects those upper bits to remain zero. Consequently, at execution time, the program operates with a register value that exceeds the bounds assumed by the security checks. This discrepancy creates a potential avenue for bypassing verification constraints, as the actual data state diverges from the verified safe state, potentially allowing access to memory regions or control flow paths that should have been prohibited.
The operational impact of this vulnerability is significant within the context of network packet filtering and eBPF program execution. Since BPF programs often run with high privileges in kernel space, any deviation from strict verification rules can lead to undefined behavior, kernel crashes, or potentially arbitrary code execution if an attacker can craft a malicious eBPF program that exploits this mismatch. The ability to manipulate register values beyond verified limits undermines the integrity of the sandboxing mechanism designed to protect the Linux kernel from untrusted user-space programs. This could allow for privilege escalation or denial of service attacks against systems relying on BPF-based network monitoring, load balancing, or security enforcement tools such as eBPF-powered firewalls and intrusion detection systems.
To mitigate this vulnerability, developers have implemented a fix that aligns the runtime instruction set with the verifier's expectations by ensuring the read value matches the assumed width of the data access. The solution involves replacing 64-bit move instructions with 32-bit move instructions, specifically using MOV32 instead of MOV64. This change ensures that when values are moved into registers, the upper bits remain zero as statically analyzed, thereby preserving the invariant required by the verifier. Additionally, the fix corrects a reporting error regarding the size of destination variables versus source fields, ensuring accurate metadata is passed to the verification engine for future checks. These changes restore consistency between static analysis and dynamic execution, closing the gap that allowed register state manipulation beyond verified limits.
From an industry standards perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system failed to properly validate or handle input data sizes during code generation relative to verifier expectations. It also relates to CWE-697 Incorrect Comparison, where the runtime value comparison diverges from the verified bounds. In terms of MITRE ATT&CK techniques, this flaw could be leveraged in conjunction with T1059 Command and Scripting Interpreter if an attacker were able to craft malicious eBPF programs that exploit these verification bypasses for lateral movement or persistence within a compromised host environment. The resolution emphasizes the importance of strict type checking and size consistency in low-level kernel code generation, particularly when dealing with security-critical subsystems like BPF where memory safety is enforced through static analysis rather than runtime bounds checks alone.