Look up another CVE · open CVE-2026-93144 in the interactive tracker
CVE-2026-93144
bpf: Reject writes through untrusted BTF pointers
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-93144 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 | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| 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_ptr_to_btf_access() lets program-type btf_struct_access callbacks validate writes before the default BTF access path rejects non-read accesses. That bypasses the read-only policy for untrusted BTF pointers created by helpers such as bpf_rdonly_cast(). Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the common entry point, before the callback branch to handle all cases.
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.18%, higher than 7.4% 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.2 | 6.18.57 | 644cf4e77c27 |
| 6.2 | 7.2.6 | 19d5566b84ca |
| 6.2 | 7.3 | ac65c710cc64 |
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 BPF bytecode that calls bpf_rdonly_cast() then STX, submitted via bpf(BPF_PROG_LOAD) in SYSCALL_DEFINE5(bpf) → bpf_prog_load() → bpf_check() → do_check_main() → check_mem_access() → check_ptr_to_btf_access(); no remote protocol carries that untrusted pointer or the store.
- AC:LAttack complexity, low
- A BPF_PROG_TYPE_STRUCT_OPS program attached to bpf_dummy_ops (check_struct_ops_btf_id() sets env->ops to bpf_dummy_ops_btf_struct_access) or a BPF_PROG_TYPE_SCHED_CLS program (tc_cls_act_btf_struct_access) does bpf_rdonly_cast() then a store; the WRITE path ran the callback before the old "only read is supported" check. No race.
- PR:LPrivileges required, low
- check_ptr_to_btf_access() returns -EPERM unless env->allow_ptr_leaks (bpf_token_capable(CAP_PERFMON)); STRUCT_OPS also fails is_perfmon_prog_type() without CAP_PERFMON, and add_subprog_and_kfunc() needs env->bpf_capable to emit bpf_rdonly_cast. bpf_token_capable() uses ns_capable() on a delegated token userns, not init-namespace root.
- UI:NUser interaction, none
- The attacker loads that program with BPF_PROG_LOAD and runs it via BPF_PROG_TEST_RUN (bpf_struct_ops_test_run() → dummy_ops_call_op() for bpf_dummy_ops, or bpf_prog_test_run_skb() for SCHED_CLS). No other user must mount, open a file, or cooperate.
- S:UScope, unchanged
- bpf_convert_ctx_accesses() leaves PTR_TO_BTF_ID|PTR_UNTRUSTED stores as plain STX (only reads become BPF_PROBE_MEM), so the write corrupts host kernel memory in the same authority as the bpf() caller; this is not a KVM/Xen guest-to-host escape or IOMMU bypass.
- C:HConfidentiality impact, high
- The accepted STX writes attacker bytes through a bpf_rdonly_cast() pointer (obj__ign skips type checks) at bpf_dummy_ops_state.val, nf_conn.mark, or tcp_sock.snd_cwnd. That type-confused kernel write is a memory-corruption primitive that can be turned into an arbitrary kernel read.
- I:HIntegrity impact, high
- bpf_dummy_ops_btf_struct_access() accepts any store within sizeof(struct bpf_dummy_ops_state), and _nf_conntrack_btf_struct_access() accepts nf_conn.mark, on a PTR_UNTRUSTED base from bpf_rdonly_cast(); the JIT emits a plain store to that address, an arbitrary kernel write usable for control-flow hijacking.
- A:HAvailability impact, high
- The same unprobed STX to bpf_rdonly_cast(0, btf_id) or to an out-of-bounds map/stack address page-faults in kernel context during bpf_struct_ops_test_run()/bpf_prog_test_run_skb() and oopses/panics, and the attacker can repeat BPF_PROG_TEST_RUN at will.