CVE-2026-90312
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's network filtering engine could let a logged-in user take over the whole machine.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability allows a local BPF program to perform an atomic load-acquire operation that bypasses source register type validation, resulting in type confusion where a register holds unconverted kernel object bytes (such as struct sk_buff) typed as a socket pointer.
Why it matters to the business
On unpatched Linux systems, local users could exploit this to escalate privileges or cause kernel crashes through memory corruption in the BPF subsystem.
How an attack unfolds
An attacker loads a malicious BPF program using an atomic load-acquire instruction where the destination and source registers are the same. This causes check_load_mem to overwrite the source type, skipping atomic_ptr_type_ok checks for disallowed pointer types like ctx or sock, leading to raw access to kernel structures after bpf_convert_ctx_accesses.
How to fix it
Update the Linux kernel to a version containing the fix that calls check_reg_arg and atomic_ptr_type_ok on the source register before the load, matching the approach used for check_atomic_rmw.
How to confirm the fix worked
Confirm the patch is present by inspecting the BPF verifier source for the reordered atomic_ptr_type_ok call; execute the atomic load selftests to ensure disallowed pointer types are rejected.
Typical attack path
- Compile and load a crafted BPF program containing an atomic load-acquire where dst_reg equals src_reg
- Pass the program through the verifier to trigger the bypassed type check
- Execute the program to perform the load and obtain a mistyped kernel pointer
- Pass NULL checks and dereference the confused pointer to access or corrupt kernel memory
How to detect it
Review audit logs and kernel verifier output for BPF programs that load atomic instructions; inspect traces for register state changes around atomic load-acquire operations.
What your security team should do
- Apply the upstream kernel fix as soon as a distribution package is available
- Disable unprivileged BPF loading via the kernel.unprivileged_bpf_disabled sysctl where feasible
- Monitor kernel update channels for BPF verifier patches and schedule testing in lab environments
The record
In the Linux kernel, the following vulnerability has been resolved: bpf: Check load-acquire src ptr type before the load check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock). Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data. Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit 503d21ef8eac ("bpf: Do register range validation early")), and the only exemption there, is_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never matches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not dereference register state out of bounds, that is, the out-of-bounds read addressed by the Fixes commit below does not reappear (as proven also via selftest).
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|