Look up another CVE · open CVE-2026-90312 in the interactive tracker
CVE-2026-90312
bpf: Check load-acquire src ptr type before the load
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem kernel/bpf. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90312 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/bpf/verifier.c
- What this is
- BPF [CORE]MAINTAINERS section matched on kernel/bpf/verifier.c · bpf@vger.kernel.org · Maintained
Check it on the machine
grep -wE 'CONFIG_BPF|CONFIG_BPF_SYSCALL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switches
- CONFIG_BPF, CONFIG_BPF_SYSCALL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 4.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- kernel/bpf
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.52 | 6ee7b0088849 |
| 6.15 | 7.2.6 | 422a41604117 |
| 6.15 | 7.3 | b87803391baa |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The attacker-controlled input is a BPF_LOAD_ACQ insn with dst_reg==src_reg in the bytecode bpf_prog_load() copies from bpf(2) BPF_PROG_LOAD (__sys_bpf). do_check_insn()→check_atomic()→check_atomic_load() then lets check_load_mem() overwrite the source type before atomic_ptr_type_ok(); no remote protocol message carries that insn.
- AC:LAttack complexity, low
- The attacker authors a SOCKET_FILTER program that does BPF_LOAD_ACQ of offsetof(__sk_buff, sk) with dst_reg==src_reg (the PTR_TO_CTX). check_load_mem() replaces that register with PTR_TO_SOCK_COMMON_OR_NULL, so type_is_sk_pointer() does not match and atomic_ptr_type_ok() accepts it. No race or uninfluenced layout is required.
- PR:LPrivileges required, low
- bpf_prog_load() allows BPF_PROG_TYPE_SOCKET_FILTER and BPF_PROG_TYPE_CGROUP_SKB without CAP_BPF when sysctl_unprivileged_bpf_disabled is 0; otherwise bpf_token_capable(CAP_BPF) is enough. bpf_token_capable() uses ns_capable() on a delegated token userns, not init-namespace root. verifier_load_acquire.c marks socket load-acquire __success_unpriv.
- UI:NUser interaction, none
- The attacker loads the program with BPF_PROG_LOAD and runs it via BPF_PROG_TEST_RUN (bpf_prog_test_run_skb on sk_filter_prog_ops) or attaches it to their own socket with setsockopt(SO_ATTACH_BPF)→sk_attach_bpf() and triggers the filter. No other user must mount or open a file.
- S:UScope, unchanged
- check_atomic_load()'s type confusion and the later interpreter/JIT smp_load_acquire plus bpf_sock_convert_ctx_access loads run in the host kernel that accepted the program. That is in-kernel privilege escalation, not a KVM/Xen guest-to-host escape or IOMMU bypass.
- C:HConfidentiality impact, high
- bpf_convert_ctx_accesses() does not rewrite BPF_ATOMIC, so load-acquire of offsetof(__sk_buff, sk) reads unconverted sk_buff bytes while the register is typed PTR_TO_SOCK_COMMON_OR_NULL. After a NULL check, later LDX of bpf_sock fields is rewritten by bpf_sock_convert_ctx_access() into struct sock loads against that pointer.
- I:HIntegrity impact, high
- The same confused PTR_TO_SOCK_COMMON is accepted as ARG_PTR_TO_SOCK_COMMON by bpf_sk_fullsock and, on CGROUP_SKB, bpf_sk_storage_get, which dereference and update sock-shaped kernel state on an object that is actually raw sk_buff memory. Commit-described verifier type confusion, not a bounded scalar leak.
- A:HAvailability impact, high
- Interpreter BPF_LOAD_ACQ does smp_load_acquire of the unconverted ctx address, and follow-on bpf_sock_convert_ctx_access LDXes dereference that value as struct sock. A non-pointer or unmapped value page-faults in kernel context; the attacker can repeat this via BPF_PROG_TEST_RUN or the attached filter.