CVE-2026-98590
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A recently fixed Linux kernel bug could let a local user trick the system into allowing unsafe access to memory, though the chance of real-world abuse remains very low.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The BPF verifier marks upper bits of a register as known-zero after a ctx load of rx_queue_mapping, but the emitted code uses BPF_MOV_IMM64 with -1 which sign-extends and, after a right-shift, produces a runtime value larger than the verifier expects, violating safety assumptions and enabling memory corruption.
Why it matters to the business
Local unprivileged users on affected Linux systems may be able to crash the kernel or escalate privileges; the flaw is five days old with negligible exploit probability and has not appeared in ransomware or state-actor campaigns.
How an attack unfolds
An attacker compiles a BPF program that reads the rx_queue_mapping field of a bpf_sock context object; the verifier accepts the program because it trusts the load size and zero-extension, yet at runtime the sign-extended -1 value produces an out-of-bounds or unexpected index that can be abused for kernel memory access.
How to fix it
Upgrade the Linux kernel to a version that contains the corrected ctx-access code generation using MOV32 instructions and correct destination size reporting for the bpf_sock field.
How to confirm the fix worked
Confirm the running kernel contains the upstream fix for bpf_sock context code generation; recompile and reload test BPF programs that exercise rx_queue_mapping loads and verify verifier and runtime behavior match expected sizes.
Typical attack path
- Obtain unprivileged local access on a Linux host
- Load a crafted BPF program that triggers the rx_queue_mapping ctx access path
- Trigger verifier acceptance followed by runtime execution of the sign-extended value
- Use the resulting out-of-bounds register value to read or write kernel memory
How to detect it
Inspect audit logs or eBPF telemetry for unusual program loads that reference bpf_sock contexts; correlate with kernel oops or panic reports mentioning ctx access or verifier register bounds.
What your security team should do
- Apply the kernel update that resolves the bpf_sock code-generation bug as soon as vendor packages are available
- Monitor upstream stable and distribution kernel changelogs for the referenced commit
- Limit unprivileged BPF loading via sysctl until patches are deployed
The record
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).
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|