CVE-2026-92517
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel on certain processors could let programs crash the system or leak small pieces of internal data when using advanced packet or tracing features.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Missing extable entries for PROBE_ATOMIC load_acquire operations in RISC-V BPF JIT cause faults to oops instead of being handled; REG_DONT_CLEAR_MARKER also leaves stale register values that the verifier assumes were overwritten, enabling leakage via maps.
Why it matters to the business
Kernel instability and potential exposure of sensitive register contents on RISC-V systems running BPF programs for networking, tracing or security, increasing crash risk and data leakage exposure in affected environments.
How an attack unfolds
An attacker loads a crafted BPF program containing sub-word load_acquire operations that can fault; the missing exception handler triggers an oops while the stale register value can be exfiltrated through a map lookup, bypassing verifier assumptions.
How to fix it
Update the Linux kernel to a version containing the fix for extable handling and register clearing in the RISC-V BPF JIT; rebuild and redeploy any out-of-tree BPF programs after the update.
How to confirm the fix worked
Confirm the patched kernel is running, then execute BPF test cases that exercise load_acquire with faulting addresses and verify no oops occurs and registers are properly zeroed on fault.
Typical attack path
- Compile and load a BPF program using atomic load_acquire on sub-word accesses that may fault
- Trigger a faulting memory access during program execution
- Observe kernel oops due to absent extable entry or leak stale register value via subsequent map operation
How to detect it
Search kernel logs and dmesg for oops or fault messages originating from the RISC-V BPF JIT around atomic load operations; inspect BPF map interactions for unexpected register values in program traces.
- bpf_jit: extable entry missing
- riscv: load_acquire fault
- PROBE_ATOMIC
What your security team should do
- Apply the kernel patch on all RISC-V systems using BPF within the next maintenance window
- Monitor kernel logs for oops entries involving bpf or riscv jit during the transition
- Re-test critical BPF programs in a staging environment before production rollout
The record
In the Linux kernel, the following vulnerability has been resolved: bpf, riscv: Fix extable handling for arena load_acquire emit_atomic_ld_st() returns 1 to have build_body() skip the zext after a sub-word load_acquire. The caller does "ret = ret ?: add_exception_handler(...)", which skips add_exception_handler() on any non-zero ret, so the extable entry is missing and a faulting PROBE_ATOMIC load_acquire oopses. REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still thinks the load overwrote it, so a program can leak it through a map. Check ret >= 0 before calling add_exception_handler(), and pass rd for LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret unchanged for the zext skip.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|