Look up another CVE · open CVE-2026-80588 in the interactive tracker
CVE-2026-80588
mptcp: reclaim forward-allocated memory on RX path errors
Published 2026-08-26 (2 months ago) by the Linux kernel CNA. Subsystem net/mptcp. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80588 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.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"), errors in the receive path prior to queueing skbs into the receive queue do not trigger forward-allocated memory reclaiming. Prevent forward memory from growing unboundedly in pathological drop scenarios by explicitly reclaiming memory when skbs are dropped.
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/mptcp/protocol.c
- What this is
- NETWORKING [MPTCP]MAINTAINERS section matched on net/mptcp/ · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_MPTCP /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 switch
- CONFIG_MPTCP
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-08-26 (2 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.61%, higher than 48.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- net/mptcp
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18.35 | 6.18.46 | 473f1a5ab2ab |
| 6.19 | 7.1.10 | 8277f48a06d3 |
| 6.19 | 7.2 | 41b49a8b914e |
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:NAttack vector, network
- Remote TCP/MPTCP peers reach the bug on the established-connection RX datapath (tcp_rcv_established → subflow_data_ready → mptcp_data_ready → __mptcp_move_skbs_from_subflow → __mptcp_move_skb → mptcp_drop) when duplicate or out-of-window mapped data is dropped before skb_set_owner_r().
- AC:LAttack complexity, low
- The attacker fully controls subflow packet contents and ordering on their MPTCP connection and can deterministically trigger drops (duplicate map_seq, OoO beyond rcv_wnd) on every crafted segment without races, rare sysctl state, or uncontrollable memory layout.
- PR:NPrivileges required, none
- No local account or kernel capability is required on the victim; any remote peer that completes the TCP/MPTCP handshake on an IPPROTO_MPTCP socket (Android clients, MPTCP-enabled servers, curl --mptcp) can flood pathological RX drops without target credentials.
- UI:NUser interaction, none
- Exploitation needs only attacker-generated MPTCP/TCP traffic on an existing or attacker-initiated connection; no victim mount, file open, click, or other cooperative user action beyond normal network stack processing.
- S:UScope, unchanged
- Impact is unbounded sk_forward_alloc growth and kernel memory exhaustion on the affected host; it does not cross VM, container, IOMMU, or sandbox boundaries to another security authority.
- C:NConfidentiality impact, none
- This is a forward-memory accounting leak on skb drop after mptcp_borrow_fwdmem(); skb data is freed and no use-after-free, out-of-bounds read, or other memory-corruption primitive exposes kernel contents to the attacker.
- I:NIntegrity impact, none
- The flaw only fails to reclaim borrowed forward allocation when dropping skbs; it does not corrupt, overwrite, or modify attacker-chosen memory and provides no write or code-execution primitive.
- A:HAvailability impact, high
- Each pre-queue drop leaks roughly skb->truesize forward memory while bypassing the removed sk_rmem_schedule guard, so a remote peer can repeatedly trigger unbounded per-connection kernel memory growth and OOM denial of service, matching CNA precedent for repeatable network skb/memory leaks.