CVE-2026-80981: net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link()
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix use-after-free of the LLC qentry in smcllcsrvaddlink()
smcllcsrvaddlink() keeps addllc pointing into the queue entry:
addllc = &qentry->msg.addlink; smcllc.c:1482 ... smcllcsaveaddlinkinfo(linknew, addllc); smcllc.c:1494 smcllcflowqentrydel(&lgr->llcflowlcl); smcllc.c:1495 ... u8 llcmsg = smclinksharedv2rxbuf(link) ? (u8 )lgr->wrrxbufv2 : (u8 )addllc; smcllc.c:1504 smcllcsaveaddlinkrkeys(link, linknew, llcmsg); smcllc.c:1506
smcllcflowqentrydel() kfree()s the entry, so on a link without a shared v2 receive buffer the pointer handed to smcllcsaveaddlinkrkeys() is already freed. Before the Fixes: commit that branch always used lgr->wrrxbufv2 and addllc was not used after the free.
Reproduced on an unpatched tree over rxe, with KASAN, kasanmultishot and a link forced to maxrecvsge == 1: the entry is freed and read by the same call, and the freeing frame is smcllcsrvaddlink() itself.
[ 2.523161] BUG: KASAN: slab-use-after-free in smcllcsaveaddlinkrkeys+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, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.523866] Workqueue: smchswq smclistenwork [ 2.523869] Call Trace: [ 2.523870] <TASK> [ 2.523871] dumpstacklvl+0x53/0x70 [ 2.523872] printreport+0xd0/0x630 [ 2.523874] ? pfxrawspinlockirqsave+0x10/0x10 [ 2.523876] ? smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.523878] kasanreport+0xce/0x100 [ 2.523879] ? smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.523881] smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.523883] ? smcrbufreglgr+0x2a4/0x660 [ 2.523885] smcllcsrvaddlink+0xaa2/0x1e50 [ 2.523888] ? printk+0xba/0xf0 [ 2.523897] ? pfxsmcllcsrvaddlink+0x10/0x10 [ 2.523899] ? downwrite+0xb0/0x130 [ 2.523903] ? pfxdownwrite+0x10/0x10 [ 2.523905] smclistenwork+0x489e/0x4d00 [ 2.523907] ? kmemcachefree+0x1c6/0x3a0 [ 2.523911] ? pfxsmclistenwork+0x10/0x10 [ 2.523913] ? releasesock+0x148/0x1d0 [ 2.523915] ? smctcplistenwork+0xb4f/0xfc0 [ 2.523917] ? rawspinlockirq+0x80/0xe0 [ 2.523918] ? pfxrawspinlockirq+0x10/0x10 [ 2.523920] processonework+0x633/0x1030 [ 2.523922] ? assignwork+0x11d/0x370 [ 2.523924] workerthread+0x45b/0xd10 [ 2.523926] ? pfxworkerthread+0x10/0x10 [ 2.523928] ? pfxworkerthread+0x10/0x10 [ 2.523929] kthread+0x2c6/0x3b0 [ 2.523931] ? recalcsigpending+0x15c/0x1e0 [ 2.523934] ? pfxkthread+0x10/0x10 [ 2.523935] retfromfork+0x36e/0x5a0 [ 2.523937] ? pfxretfromfork+0x10/0x10 [ 2.523938] ? switchto+0x572/0xdd0 [ 2.523943] ? pfxkthread+0x10/0x10 [ 2.523944] retfromforkasm+0x1a/0x30 [ 2.523947] </TASK> [ 2.523948] [ 2.531253] Allocated by task 48: [ 2.531399] kasansavestack+0x33/0x60 [ 2.531570] kasansavetrack+0x14/0x30 [ 2.531737] kasankmalloc+0x8f/0xa0 [ 2.531905] kmalloccachenoprof+0x158/0x370 [ 2.532100] smcllcenqueue+0x72/0x560 [ 2.532268] smcwrrxtaskletfn+0x474/0xa80 [ 2.532491] taskletactioncommon+0x20f/0x8a0 [ 2.532714] handlesoftirqs+0x18e/0x590 [ 2.532886] dosoftirq+0x3b/0x60 [ 2.533036] localbhenableip+0x61/0x70 [ 2.533221] allocskb+0x732/0x890 [ 2.533384] rxeinitpacket+0x16b/0x4f0 [ 2.533567] prepareackpacket+0xb8/0x830 [ 2.533760] rxereceiver+0x495/0x96e0 [ 2.533933] dowork+0x144/0x470 [ 2 ---truncated---
Affected Software
Event History
Frequently Asked Questions
What systems are most likely to encounter this issue?
The issue is in the Linux kernel SMC networking code during server-side link addition. It was reproduced over RXE when a link was forced to use max_recv_sge == 1, a condition that results in no shared v2 receive buffer being used.
What condition causes the use-after-free?
The affected path retains a pointer into an LLC queue entry, deletes the queue entry, and then passes that stale pointer to smc_llc_save_add_link_rkeys() when the link does not have a shared v2 receive buffer. Deleting the queue entry frees its memory before the later read occurs.
How can an affected kernel be identified?
A KASAN-enabled affected kernel can report a slab-use-after-free in smc_llc_save_add_link_rkeys() while handling server-side SMC link addition. The reported reproduction used RXE, kasan_multi_shot, and a link forced to max_recv_sge == 1.