Look up another CVE · open CVE-2026-80985 in the interactive tracker
CVE-2026-80985
net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem net/smc. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80985 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.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
smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part of a v2 message that does not fit into the 44-byte union smc_llc_msg, and both bound themselves by the size of the buffer it landed in, not by what arrived. On a link with a shared v2 receive buffer a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an earlier message left in lgr->wr_rx_buf_v2, and passes each of them to smc_rtoken_delete(). One of those 255 matched a registered rtoken and deleted it. An ADD_LINK on such a link installs up to 255 rtokens from the same bytes. Copy the tail into the queue entry, so its length is the length of the message that arrived, and declare the rkeys that fit inline as a member of the union instead of reaching them through a cast. The same DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited to the longest tail the two functions can read, so the peer does not pick the size of the entry. The bound the previous patch placed on links without a shared v2 receive buffer is no longer needed.
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/smc_llc.c
net/smc/smc_wr.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 2 releases, so the answer depends on which release the machine runs.
- bookworm, trixiem
- forky, sidn
- 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-09-11 (37 days ago)source
- CVSS
- 8.2 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.53%, higher than 43.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.14 | 6.18.50 | edf30d65e3ac |
| 6.14 | 7.2.4 | 0d6f80be8ac5 |
| 6.14 | 7.3 | 8d3c1ab82c11 |
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
- A remote SMC-Rv2 peer delivers DELETE_RKEY_V2 and ADD_LINK LLC messages over the RDMA QP after the TCP CLC handshake; RoCEv2 is IP/UDP-routable (port 4791) and SMC-Rv2 supports routed peers. smc_llc_rx_handler runs from the RDMA completion path with no local syscall.
- AC:LAttack complexity, low
- The attacker controls the prior oversized LLC payload that fills the shared lgr->wr_rx_buf_v2 spillover and the later 44-byte DELETE_RKEY_V2 or ADD_LINK that declares up to 255 rkeys, so leftover bytes are attacker-chosen. No race, lucky layout, or rare non-default config is required on the usual max_recv_sge>=2 path.
- PR:NPrivileges required, none
- SMC performs no peer authentication; smc_create() has no capability check, and LLC DELETE_RKEY/ADD_LINK run after an unauthenticated CLC handshake. Any network peer that completes SMC-R v2 to a listener reaches smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys().
- UI:NUser interaction, none
- Incoming LLC messages are demultiplexed from the RDMA receive completion tasklet into smc_llc_event_work. A listening SMC-R server processes DELETE_RKEY_V2 automatically with no victim user action.
- S:UScope, unchanged
- The corrupted rtoken table lives in the same kernel security authority as the SMC-R stack; this does not cross a VM, IOMMU, or sandbox boundary.
- C:NConfidentiality impact, none
- Leftover bytes are prior peer LLC payloads in the shared 8KiB wr_rx_buf_v2, not adjacent kernel objects, so the extra rkey walks do not disclose kernel memory. Rtokens are remote keys used only for outbound RDMA writes to that same peer.
- I:LIntegrity impact, low
- Leftover rkeys are passed to smc_rtoken_delete() and leftover ADD_LINK extensions are written via smc_rtoken_set(), so registered rtokens can be cleared or remapped on a new link. That is limited corruption of the LGR rtoken table, not an arbitrary kernel write.
- A:HAvailability impact, high
- Deleting a live rtoken zeros its rkey and dma_addr while connections still use that slot, so later smc_tx_rdma_write() posts fail and smcr_link_down tears down the link group. A peer can repeat this at will and fully deny SMC-R on the LGR.