CVE-2026-90269 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject load-acquire from pointers requiring fault protection
A BPF_LOAD_ACQ is not rewritten to a BPF_PROBE_MEM load by the verifier, unlike a regular BPF_LDX, so the JIT emits a plain load with no exception table entry and a fault panics the kernel instead of being handled.
Reject the source pointer types that a BPF_LDX would have had that fault protection applied to, i.e. the ones bpf_convert_ctx_accesses() turns into BPF_PROBE_MEM: a bare PTR_TO_BTF_ID, PTR_TO_BTF_ID | PTR_UNTRUSTED, PTR_TO_BTF_ID | MEM_ALLOC | PTR_UNTRUSTED and PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED.
This is reachable e.g. by loading ->mm out of a trusted task_struct yields an untrusted pointer to mm_struct, and it is NULL for a kernel thread:
[...]
SEC("tp_btf/sched_switch") int BPF_PROG(demo, bool preempt, struct task_struct *prev, struct task_struct *next) {
struct mm_struct *mm = next->mm; /* untrusted */
out_ldx = (__u64)mm->pgd; /* BPF_LDX */ out_acq = load_acquire(&mm->pgd); /* BPF_LOAD_ACQ */ return 0; } [...]
Both dereference the same pointer, but only the BPF_LDX is protected (x86-64 JIT, jump targets shown prog-relative):
[...]
; out_ldx = (__u64)mm->pgd; 17: movq $-10485760, %r10 1e: movq %rsi, %r11 21: addq $184, %r11 28: subq %r10, %r11 2b: movabsq $140737498841088, %r10 35: cmpq %r10, %r11 38: ja 0x3e <-- kernel addr? 3a: xorl %edi, %edi <-- no: dst = 0, skip the load 3c: jmp 0x45 3e: movq 184(%rsi), %rdi <-- yes: load + extable entry [...]
; load_acquire(&mm->pgd) 53: movq %rsi, %rdi 56: movq 184(%rdi), %rax <-- no check, no extable entry [...]
Note that BPF_PROBE_MEM is not visible in a bpftool xlated dump, as bpf_insn_prepare_dump() rewrites it back to BPF_MEM.
A PTR_TRUSTED pointer is deliberately not on the list. Such a load is not converted either, but it does not need to be, since the pointer is guaranteed live, so load-acquire from it stays allowed.
The check is gated on BPF_LOAD_ACQ so that atomic RMW and store-release error messages are unchanged; writes (RMW / store-release) to such pointers are already rejected elsewhere, so only load-acquire needs this.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
A critical vulnerability in the Linux kernel's Berkeley Packet Filter subsystem allows for a denial of service through kernel panic when unprivileged or improperly validated BPF programs attempt to use atomic load operations on memory addresses that require fault protection. The root cause lies in an inconsistency within the verifier logic, specifically regarding how different instruction types are handled during code generation and validation. While standard load instructions such as BPF_LDX are correctly rewritten into BPF_PROBE_MEM variants by the verifier, which subsequently generates exception table entries to handle page faults gracefully, atomic load-acquire operations designated as BPF_LOAD_ACQ bypass this transformation mechanism. Consequently, the Just-In-Time compiler emits a plain memory load instruction without any associated fault handling infrastructure. If such an operation targets a kernel address that is not mapped or accessible, rather than triggering a controlled exception and returning an error code to the user space program, it causes an immediate unrecoverable page fault leading to a system-wide kernel panic.
The technical flaw stems from the verifier's failure to apply necessary safety checks for specific pointer types when atomic loads are involved. The vulnerability affects scenarios where BPF programs attempt to dereference pointers that have been marked as untrusted or require memory access protection, such as bare PTR_TO_BTF_ID pointers, those combined with PTR_UNTRUSTED flags, or allocations involving MEM_ALLOC and PTR_UNTRUSTED combinations. A typical exploitation vector involves a program attached to trace points like sched_switch attempting to read fields from task structures. For instance, accessing the mm_struct pointer of a next process can yield an untrusted pointer if that process is a kernel thread where the memory descriptor is null or invalid. When the BPF code uses a standard load instruction for this field, the verifier inserts bounds checking and fault protection logic into the generated machine code. However, when the same field is accessed using a C atomic load operation which compiles to BPF_LOAD_ACQ, the verifier fails to inject these protective measures, leaving the execution path vulnerable to crashes upon invalid memory access.
This issue maps directly to CWE-401 Missing Release of Memory after Successful Extraction and CWE-787 Out-of-bounds Read in terms of improper resource handling and unsafe memory access patterns within the kernel context. From an offensive security perspective aligned with MITRE ATT&CK, this vulnerability facilitates Denial of Service via system crash (T1529) by exploiting a logic error in privileged code execution paths. The impact is severe as it allows any user capable of loading BPF programs to destabilize the entire host system without requiring privilege escalation beyond initial program load permissions. The distinction between trusted and untrusted pointers remains critical; while PTR_TRUSTED pointers are excluded from this restriction because they guarantee liveness and valid memory presence, all other categories that typically trigger fault protection mechanisms must now be explicitly rejected for atomic loads to maintain system stability.
Mitigation requires the immediate application of kernel patches that enforce consistent validation rules across both standard and atomic load instructions within the BPF verifier. The fix involves extending the rejection logic used for regular loads to also cover BPF_LOAD_ACQ operations when applied to untrusted or potentially invalid pointer types. System administrators should ensure their Linux kernels are updated to versions containing this specific patch, which explicitly rejects source pointer types that would normally trigger fault protection if accessed via standard load instructions. This includes rejecting accesses to bare PTR_TO_BTF_ID pointers and those with untrusted flags unless they are confirmed as trusted references guaranteed to be live in memory. Until patched, administrators should restrict BPF program loading capabilities to highly privileged users only and monitor for unusual kernel oops or panic logs indicating invalid memory access from eBPF programs.