CVE-2026-90269
Description
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.
How to fix
- Linux Linuxc4c8de3bf48d3756ab0f910fe5cc4937d70efdcd, 5f8ade6e9b7931fc9697394f1b2c4ae833f5ac18, 7db0a00445f1a40bacfe9b747405c11cb5f10fc9 or later
Affected products
| Product | Affected versions | Fixed in |
|---|---|---|
| Linux Linux | 880442305a3908589bf4d6fc1d79edb577ee497c ≤ v < c4c8de3bf48d3756ab0f910fe5cc4937d70efdcd, 880442305a3908589bf4d6fc1d79edb577ee497c ≤ v < 5f8ade6e9b7931fc9697394f1b2c4ae833f5ac18, 880442305a3908589bf4d6fc1d79edb577ee497c ≤ v < 7db0a00445f1a40bacfe9b747405c11cb5f10fc9, 6.15 | c4c8de3bf48d3756ab0f910fe5cc4937d70efdcd, 5f8ade6e9b7931fc9697394f1b2c4ae833f5ac18, 7db0a00445f1a40bacfe9b747405c11cb5f10fc9 |
Check your version
Choose the product and enter the version you run to see whether it falls in the affected range.
Attack Surface Management
See the assets tied to your domains, the technologies they run and known vulnerabilities in one list.