Look up another CVE · open CVE-2026-74282 in the interactive tracker
CVE-2026-74282
tipc: prevent snt_unacked underflow on CONN_ACK
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem net/tipc. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-74282 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 | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: tsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack.
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/tipc/socket.c
- What this is
- TIPC NETWORK LAYERMAINTAINERS section matched on net/tipc/ · netdev@vger.kernel.org · Maintained
- Kernel module
- tipc
Check it on the machine
grep -w CONFIG_TIPC /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.
lsmod | grep -w tipcPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_TIPC
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-15 (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.70%, higher than 52.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/tipc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.7 | 5.10.261 | 3388145d258c |
| 4.7 | 5.15.212 | 67e55b054bf8 |
| 4.7 | 6.1.178 | 96f91b8ae1a4 |
| 4.7 | 6.6.145 | 47ed873e4ced |
| 4.7 | 6.12.97 | b44bebdd32c9 |
| 4.7 | 6.18.40 | 3cfa3d8e0dc1 |
| 4.7 | 7.1.5 | 1e2c95674577 |
| 4.7 | 7.2 | ab3e10b44ba5 |
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
- The flaw is reached when tipc_rcv() processes a remote CONN_MANAGER/CONN_ACK skb from a TIPC bearer (UDP port 6118 or Ethernet), traversing tipc_link_rcv()→tipc_sk_rcv()→tipc_sk_proto_rcv()→tipc_sk_conn_proto_rcv() with attacker-controlled ack count.
- AC:LAttack complexity, low
- After a normal TIPC connect handshake, the connected peer can send a single CONN_ACK whose msg_conn_ack() exceeds snt_unacked; no races, timing, or rare layout conditions are needed and the malicious field is fully attacker-controlled.
- PR:NPrivileges required, none
- Exploitation only requires becoming the established TIPC peer via a standard AF_TIPC connect/listen handshake; socket creation needs no capabilities and the protocol has no authentication gate before CONN_ACK processing.
- UI:NUser interaction, none
- No victim user action is required beyond the service already accepting TIPC connections; the attacker triggers the bug by sending one crafted CONN_ACK on the established connection.
- S:UScope, unchanged
- Impact is limited to corrupting flow-control state on a victim TIPC socket within the same kernel/host security boundary; there is no VM escape, container breakout, or IOMMU boundary crossing.
- C:NConfidentiality impact, none
- The unsigned 16-bit underflow only corrupts the snt_unacked congestion counter and does not read or disclose kernel memory, pointers, or other sensitive information.
- I:NIntegrity impact, none
- The bug modifies only an internal send-window counter to block transmits and provides no arbitrary write, code execution, or user/kernel data modification primitive.
- A:HAvailability impact, high
- An oversized CONN_ACK wraps snt_unacked to a near-maximum value, leaving tsk_conn_cong() permanently true and indefinitely starving the victim socket's transmit path until the connection is torn down.