Look up another CVE · open CVE-2026-93148 in the interactive tracker
CVE-2026-93148
bpf: Reject MEM_ALLOC BTF accesses past object bounds
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem include/linux. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-93148 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
BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either.
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.
include/linux/bpf.h
kernel/bpf/btf.c
kernel/bpf/verifier.c
- What this is
- BPF [CORE]MAINTAINERS section matched on include/linux/bpf* · 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.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- include/linux
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 | cf08ff2255de |
| 6.2 | 7.2.6 | e626a50d07d4 |
| 6.2 | 7.3 | 9c9ee0324c77 |
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 program BTF (a struct whose last member is a 0-element array) plus LDX/STX offsets in bytecode that bpf_prog_load() copies from bpf(2) BPF_PROG_LOAD (__sys_bpf). bpf_check() then check_mem_access()->check_ptr_to_btf_access()->btf_struct_access()->btf_struct_walk() on the bpf_obj_new PTR_TO_BTF_ID|MEM_ALLOC; no remote protocol carries that BTF or those offsets.
- AC:LAttack complexity, low
- The attacker defines the local struct with a trailing nelems==0 array, calls bpf_obj_new (allocated at ret_t->size via bpf_mem_alloc(&bpf_global_ma)), then LDX/STX at off past t->size. Pre-fix btf_struct_walk() applied the flexible-array relaxation whenever off+size > t->size; no race or uninfluenced layout is required.
- PR:LPrivileges required, low
- add_subprog_and_kfunc() returns -EPERM unless env->bpf_capable (bpf_token_capable(CAP_BPF)) because bpf_obj_new is a kfunc; check_ptr_to_btf_access() also needs bpf_allow_ptr_leaks() (CAP_PERFMON). BPF_PROG_TYPE_SYSCALL is not is_perfmon_prog_type(); bpf_token_capable() uses ns_capable() on a delegated token userns, not init-namespace root.
- UI:NUser interaction, none
- The attacker BPF_PROG_LOADs that program and runs it with BPF_PROG_TEST_RUN (bpf_prog_test_run_syscall) so bpf_obj_new() and the OOB LDX/STX execute in that same task. No other user must mount a filesystem, open a file, or otherwise cooperate.
- S:UScope, unchanged
- btf_struct_walk() approving the flexible-array access causes the JIT/interpreter to LDX/STX past the bpf_mem_alloc() object in bpf_global_ma in the same host kernel that loaded the program. That is in-kernel heap OOB and privilege escalation, not a KVM/Xen guest-to-host escape or IOMMU bypass.
- C:HConfidentiality impact, high
- For a MEM_ALLOC object whose last BTF member is a 0-element int array, btf_struct_walk() returned WALK_SCALAR for any off past the FAM with no upper bound. bpf_convert_ctx_accesses() does not rewrite PTR_TO_BTF_ID|MEM_ALLOC to BPF_PROBE_MEM, so those LDXes are plain loads of adjacent bpf_mem_cache/kmalloc objects.
- I:HIntegrity impact, high
- check_ptr_to_btf_access() permits BPF_WRITE on type_is_ptr_alloc_obj() (PTR_TO_BTF_ID|MEM_ALLOC). The same FAM relaxation therefore approves STX past bpf_obj_new()'s ret_t->size into the bpf_global_ma size-class unit (padding and the next object), a controllable kernel heap write. btf_struct_ids_match walking past those bounds can also mis-type kptr/kfunc pointers.
- A:HAvailability impact, high
- Unbounded LDX/STX past the bpf_obj_new allocation in bpf_global_ma can corrupt adjacent bpf_mem_cache units or load unmapped addresses, oopsing or panicking the kernel when the program runs under bpf_prog_test_run_syscall, and the attacker can repeat that run at will.