Look up another CVE · open CVE-2026-74692 in the interactive tracker
CVE-2026-74692
net/smc: fix TOCTOU race between smc_listen_out() and listener close
Published 2026-08-22 (2 months ago) by the Linux kernel CNA. Subsystem net/smc. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-74692 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 | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| 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. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition: smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */ smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory. Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock.
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/smc/af_smc.c
- What this is
- SHARED MEMORY COMMUNICATIONS (SMC) SOCKETSMAINTAINERS section matched on net/smc/ · linux-rdma@vger.kernel.org · Supported
- Kernel module
- smc
Check it on the machine
grep -w CONFIG_SMC /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 smcPrints 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 does not build this code in 2 releases. It does build it in 3 releases, so the answer depends on which release the machine runs.
- bookworm, trixiem
- forky, sidn
- bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- n
- not enabled on any flavour - this release does not build the code
- Build switch
- CONFIG_SMC
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-22 (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.49%, higher than 40.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/smc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.1 | 5.15.216 | 53c7938d8bcf |
| 5.1 | 6.1.183 | feb71634bb1a |
| 5.1 | 6.6.152 | 01865e1ddb12 |
| 5.1 | 6.12.104 | 00f894337772 |
| 5.1 | 6.18.45 | 78e5ebcd1c10 |
| 5.1 | 7.1.9 | ff5bcd804b5b |
| 5.1 | 7.2 | 185a4caeecab |
| 4.19.299 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-1 | tracker |
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 bug fires when smc_listen_work() on smc_hs_wq finishes an inbound SMC/TCP handshake queued by smc_tcp_listen_work() for each remote connection to an AF_SMC listener, so any network peer that reaches the listener port drives the full path via SYN and CLC messages.
- AC:LAttack complexity, low
- The attacker controls handshake completions by flooding SMC-capable TCP connections and overlapping them with listener close(), either by timing floods against restarts or locally by running server and client together; smc_close_active() only flushes tcp_listen_work, leaving smc_hs_wq workers racing through the unlocked sk_state check.
- PR:NPrivileges required, none
- SMC performs no authentication; smc_create() and smc_listen() enforce no capabilities, and smc_listen_work() processes the CLC handshake immediately after TCP accept before any credential verification, so an unauthenticated remote peer need only reach the listener port.
- UI:NUser interaction, none
- Exploitation requires only inbound network connections and kernel handshake/close processing; no end-user action such as opening a file or mounting a filesystem is needed, and listener shutdown during deployments or restarts is routine automated server behavior.
- S:UScope, unchanged
- The leak accumulates orphaned smc_sock structures and clcsock references within the kernel networking subsystem on the targeted host; it does not cross VM, container, IOMMU, or other security boundaries.
- C:NConfidentiality impact, none
- The bug is an unreleased sock_hold() leaving child sockets on a closed listener accept queue; objects are never freed prematurely, so there is no out-of-bounds read, use-after-free dereference, or kernel data disclosure to the attacker.
- I:NIntegrity impact, none
- Only reference counts are incremented without matching decrements; no memory is written out of bounds, no freed object is reused, and no control-flow or integrity primitive is obtained—only unreclaimable kernel allocations accumulate.
- A:HAvailability impact, high
- Each successful race permanently leaks a child smc_sock, its clcsock, and sock references that smc_close_cleanup_listen() can never drain; a remote peer repeating handshakes during listener close can exhaust kernel memory and cause system-wide denial of service.