Look up another CVE · open CVE-2026-80738 in the interactive tracker
CVE-2026-80738
bpf: Check sk_state before sk_protocol in bpf_tcp_*_syncookie
Published 2026-09-03 (2 months ago) by the Linux kernel CNA. Subsystem net/core. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-80738 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| 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.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie accept a socket pointer 'sk' with argument type ARG_PTR_TO_BTF_ID_SOCK_COMMON. However, they access sk->sk_protocol without validating whether 'sk' represents a full socket. Fix this issue by checking sk->sk_state != TCP_LISTEN before inspecting sk->sk_protocol in both bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie. Since mini-sockets are never in the TCP_LISTEN state, the condition short-circuits and prevents dereferencing fullsock-specific fields.
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.
net/core/filter.c
- What this is
- BPF [GENERAL] (Safe Dynamic Programs and Tools)MAINTAINERS section matched on net/core/filter.c · bpf@vger.kernel.org · Supported
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
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 Debian linux-config packages
Signals
- Published
- 2026-09-03 (2 months ago)source
- CVSS
- 7.3 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Lsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/core
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.2 | 6.18.57 | 22c2169770ad |
| 5.2 | 7.1.9 | 23f682083aa3 |
| 5.2 | 7.2 | 31a420a822ff |
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 flaw is in bpf_tcp_gen_syncookie/bpf_tcp_check_syncookie BPF helpers invoked only from locally loaded and attached TC clsact or XDP programs via bpf(); per kernel CNA guidance BPF/tc paths are Local even when later triggered by ingress packets.
- AC:LAttack complexity, low
- An attacker who loads the BPF program fully controls passing bpf_skc_lookup_tcp() results (request_sock/TCP_NEW_SYN_RECV or timewait sockets) into the syncookie helpers and can reliably trigger the bad sk_protocol read with crafted SYN/ACK traffic; no uncontrollable races or rare layout are required.
- PR:LPrivileges required, low
- Exploitation requires bpf(BPF_PROG_LOAD) (CAP_BPF, obtainable in user namespaces) plus attaching TC/XDP hooks (CAP_NET_ADMIN via unshare -Urn); no init-namespace root is needed, matching CNA guidance for namespace-reachable net/BPF capabilities.
- UI:NUser interaction, none
- No victim mount, login, or cooperative action is required; once the attacker loads and attaches their BPF program, sending network packets from their own processes deterministically reaches the vulnerable helper on each matching lookup.
- S:UScope, unchanged
- Impact is confined to kernel heap disclosure/type confusion within the host kernel security domain; it does not cross VM, container runtime, IOMMU, or other security-authority boundaries.
- C:HConfidentiality impact, high
- Casting a mini-socket to struct sock and reading sk_protocol performs a fixed-offset out-of-bounds read (~300+ bytes past request_sock/inet_timewait_sock) into adjacent slab memory, leaking kernel heap contents including pointers usable for further local exploitation.
- I:HIntegrity impact, high
- This is type confusion between ARG_PTR_TO_BTF_ID_SOCK_COMMON mini-sockets and full struct sock fields; per CNA guidance type confusion is rated High integrity impact even though the immediate bug is a read, because mis-typed socket pointers corrupt the kernel's object model.
- A:LAvailability impact, low
- The primary impact is information disclosure; while the out-of-bounds u16 read usually stays within the slab page, reads near allocation boundaries or under KASAN can fault and oops the kernel, giving at least Low availability impact when uncertain.