Look up another CVE · open CVE-2026-80981 in the interactive tracker

CVE-2026-80981

net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link()

9.8 EPSS 0.6% AV:N

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-80981 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_srv_add_link() keeps add_llc pointing into the queue entry: add_llc = &qentry->msg.add_link; smc_llc.c:1482 ... smc_llc_save_add_link_info(link_new, add_llc); smc_llc.c:1494 smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); smc_llc.c:1495 ... u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ? (u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; smc_llc.c:1504 smc_llc_save_add_link_rkeys(link, link_new, llc_msg); smc_llc.c:1506 smc_llc_flow_qentry_del() kfree()s the entry, so on a link without a shared v2 receive buffer the pointer handed to smc_llc_save_add_link_rkeys() is already freed. Before the Fixes: commit that branch always used lgr->wr_rx_buf_v2 and add_llc was not used after the free. Reproduced on an unpatched tree over rxe, with KASAN, kasan_multi_shot and a link forced to max_recv_sge == 1: the entry is freed and read by the same call, and the freeing frame is smc_llc_srv_add_link() itself. [ 2.523161] BUG: KASAN: slab-use-after-free in smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523499] Read of size 2 at addr ffff8880052194de by task kworker/0:1/11 [ 2.523789] [ 2.523862] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5-p0-g2c9dd296545d #35 PREEMPT(lazy) [ 2.523865] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.523866] Workqueue: smc_hs_wq smc_listen_work [ 2.523869] Call Trace: [ 2.523870] <TASK> [ 2.523871] dump_stack_lvl+0x53/0x70 [ 2.523872] print_report+0xd0/0x630 [ 2.523874] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.523876] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523878] kasan_report+0xce/0x100 [ 2.523879] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523881] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523883] ? smcr_buf_reg_lgr+0x2a4/0x660 [ 2.523885] smc_llc_srv_add_link+0xaa2/0x1e50 [ 2.523888] ? _printk+0xba/0xf0 [ 2.523897] ? __pfx_smc_llc_srv_add_link+0x10/0x10 [ 2.523899] ? down_write+0xb0/0x130 [ 2.523903] ? __pfx_down_write+0x10/0x10 [ 2.523905] smc_listen_work+0x489e/0x4d00 [ 2.523907] ? kmem_cache_free+0x1c6/0x3a0 [ 2.523911] ? __pfx_smc_listen_work+0x10/0x10 [ 2.523913] ? release_sock+0x148/0x1d0 [ 2.523915] ? smc_tcp_listen_work+0xb4f/0xfc0 [ 2.523917] ? _raw_spin_lock_irq+0x80/0xe0 [ 2.523918] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 2.523920] process_one_work+0x633/0x1030 [ 2.523922] ? assign_work+0x11d/0x370 [ 2.523924] worker_thread+0x45b/0xd10 [ 2.523926] ? __pfx_worker_thread+0x10/0x10 [ 2.523928] ? __pfx_worker_thread+0x10/0x10 [ 2.523929] kthread+0x2c6/0x3b0 [ 2.523931] ? recalc_sigpending+0x15c/0x1e0 [ 2.523934] ? __pfx_kthread+0x10/0x10 [ 2.523935] ret_from_fork+0x36e/0x5a0 [ 2.523937] ? __pfx_ret_from_fork+0x10/0x10 [ 2.523938] ? __switch_to+0x572/0xdd0 [ 2.523943] ? __pfx_kthread+0x10/0x10 [ 2.523944] ret_from_fork_asm+0x1a/0x30 [ 2.523947] </TASK> [ 2.523948] [ 2.531253] Allocated by task 48: [ 2.531399] kasan_save_stack+0x33/0x60 [ 2.531570] kasan_save_track+0x14/0x30 [ 2.531737] __kasan_kmalloc+0x8f/0xa0 [ 2.531905] __kmalloc_cache_noprof+0x158/0x370 [ 2.532100] smc_llc_enqueue+0x72/0x560 [ 2.532268] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.532491] tasklet_action_common+0x20f/0x8a0 [ 2.532714] handle_softirqs+0x18e/0x590 [ 2.532886] do_softirq+0x3b/0x60 [ 2.533036] __local_bh_enable_ip+0x61/0x70 [ 2.533221] __alloc_skb+0x732/0x890 [ 2.533384] rxe_init_packet+0x16b/0x4f0 [ 2.533567] prepare_ack_packet+0xb8/0x830 [ 2.533760] rxe_receiver+0x495/0x96e0 [ 2.533933] do_work+0x144/0x470 [ 2 ---truncated---

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

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 smc

Prints 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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-09-11 (37 days ago)source
CVSS: 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.63%, higher than 49.2% 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	c52a998a223e
6.14	7.2.4	adef84cc85d4
6.14	7.3	a42a459ef0e5

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 UAF is reached from smc_listen_work() (smc_listen_rdma_finish → smcr_serv_conf_first_link → smc_llc_srv_add_link) and from LLC ADD_LINK handling; CLC is plain TCP and SMC-Rv2/RoCEv2 LLC messages are IP-routable (UDP/4791), so a remote peer that can reach an AF_SMC listener drives the path.
AC:LAttack complexity, low: The kfree of the LLC qentry and the later read in smc_llc_save_add_link_rkeys() run sequentially in the same call with no race; on an affected SMC-Rv2 link (max_recv_sge==1, the devices this bug exists for) a connecting peer that completes first-contact and replies to ADD_LINK triggers it reliably.
PR:NPrivileges required, none: smc_listen_work() runs the CLC/LLC handshake after TCP accept and before accept() returns to userspace; SMC authenticates nothing, and smc_create()/smc_listen() enforce no capabilities, so an unauthenticated network peer needs only reachability to the listener.
UI:NUser interaction, none: The listen worker is queued automatically from smc_tcp_listen_work() for inbound connections; no local user action such as mounting a filesystem or opening a file is required.
S:UScope, unchanged: The use-after-free corrupts kernel heap state (the kmalloc-96 LLC qentry and link-group rtoken tables) within the same host kernel security authority; it is not a VM escape, IOMMU bypass, or sandbox boundary crossing.
C:HConfidentiality impact, high: The dangling add_llc pointer is a use-after-free read of a freed kmalloc-96 qentry (KASAN: slab-use-after-free in smc_llc_save_add_link_rkeys); per kernel CNA guidance a UAF of a generic slab object enables arbitrary kernel memory disclosure via heap reuse.
I:HIntegrity impact, high: smc_ib_ready_link()/smcr_buf_reg_lgr() allocate between the free and the UAF, so the object can be sprayed; smc_llc_save_add_link_rkeys() then writes those bytes into lgr->rtokens, a UAF-backed write primitive usable for arbitrary kernel modification or control-flow hijack.
A:HAvailability impact, high: KASAN reports slab-use-after-free in smc_llc_save_add_link_rkeys() from smc_listen_work on smc_hs_wq; dereferencing freed heap from that kworker oopses or panics the kernel, and a remote peer can repeat the handshake at will.