CVE-2026-80986: net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
In the Linux kernel, the following vulnerability has been resolved:
net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
On a link whose device has maxrecvsge == 1 there is no shared v2 receive buffer, and smcllcsaveaddlinkrkeys() takes the v2 extension from 44 bytes past the start of the queue entry's inline message:
ext = (struct smcllcmsgaddlinkv2ext )(llcmsg + SMCWRTXSIZE);
The entry is a 72-byte allocation and the extension starts at offset 68, so ext->numrkeys at offset 94 is already past it. This happens on every SMC-Rv2 link addition, whatever the peer sends:
[ 2.490065] BUG: KASAN: slab-out-of-bounds in smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.490431] Read of size 2 at addr ffff8880056406de by task smctest/106 [ 2.490709] [ 2.490792] CPU: 0 UID: 0 PID: 106 Comm: smctest Not tainted 7.2.0-rc5-p1-g77a5d9d9c99f #32 PREEMPT(lazy) [ 2.490795] 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.490798] Call Trace: [ 2.490803] <TASK> [ 2.490805] dumpstacklvl+0x53/0x70 [ 2.490810] printreport+0xd0/0x630 [ 2.490828] ? pfxrawspinlockirqsave+0x10/0x10 [ 2.490832] ? smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.490834] kasanreport+0xce/0x100 [ 2.490836] ? smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.490837] smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.490839] ? smcrbufmaplgr+0x1bf/0x2b0 [ 2.490844] smcllccliaddlink+0xca7/0x1e80 [ 2.490848] ? smcllcwait+0x355/0x810 [ 2.490850] ? pfxsmcllcwait+0x10/0x10 [ 2.490851] ? pfxsmcllccliaddlink+0x10/0x10 [ 2.490853] ? pfxautoremovewakefunction+0x10/0x10 [ 2.490863] smcconnect+0x3f5c/0x4980 [ 2.490873] ? pfxkernelconnect+0x10/0x10 [ 2.490888] ? pfxsmcconnect+0x10/0x10 [ 2.490891] ? releasesock+0x148/0x1d0 [ 2.490894] smcconnect+0x42c/0x580 [ 2.490896] sysconnect+0xfc/0x130 [ 2.490898] ? pfxsysconnect+0x10/0x10 [ 2.490900] ? handlemmfault+0x1a1/0x430 [ 2.490908] x64sysconnect+0x6d/0xb0 [ 2.490909] ? fpregsassertstateconsistent+0x56/0xe0 [ 2.490917] dosyscall64+0xf9/0x540 [ 2.490921] entrySYSCALL64afterhwframe+0x77/0x7f [ 2.490924] RIP: 0033:0x421bb4 [ 2.490927] Code: ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d ad 34 09 00 00 74 13 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 55 [ 2.490929] RSP: 002b:00007ffd473b01a8 EFLAGS: 00000202 ORIGRAX: 000000000000002a [ 2.490935] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000421bb4 [ 2.490936] RDX: 0000000000000010 RSI: 00007ffd473b01d0 RDI: 0000000000000003 [ 2.490937] RBP: 0000000000003930 R08: 0000000000000004 R09: 0000000000000000 [ 2.490938] R10: 00007ffd473b0f98 R11: 0000000000000202 R12: 0000000000000006 [ 2.490939] R13: 00007ffd473b0f87 R14: 0000000000000003 R15: 00007ffd473b0f90 [ 2.490940] </TASK> [ 2.490941] [ 2.499545] Allocated by task 44: [ 2.499693] kasansavestack+0x33/0x60 [ 2.499860] kasansavetrack+0x14/0x30 [ 2.500026] kasankmalloc+0x8f/0xa0 [ 2.500190] kmalloccachenoprof+0x158/0x370 [ 2.500393] smcllcenqueue+0x72/0x560 [ 2.500559] smcwrrxtaskletfn+0x474/0xa80 [ 2.500747] taskletactioncommon+0x20f/0x8a0 [ 2.500945] handlesoftirqs+0x18e/0x590 [ 2.501115] dosoftirq+0x3b/0x60 [ 2.501266] localbhenableip+0x61/0x70 [ 2.501446] allocskb+0x732/0x890 [ 2.501604] rxeinitpacket+0x16b/0x4f0 [ 2.501783] prepareackpacket+0xb8/0x830 [ 2.501962] rxereceiver+0x495/0x96e0 [ 2.502125] dowork+0x144/0x470 [ 2.502269] processonework+0x633/0x1030 [ 2.502450] workerthread+0x45b/0xd10 [ 2.50261 ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Fixed in 7.2.0-rc5-p1-g77a5d9d9c99f - Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects SMC-Rv2 link additions on links whose device reports max_recv_sge equal to 1. On those devices, there is no shared v2 receive buffer and processing the v2 extension can read beyond the queue entry allocation.
Does exploitation require a malformed message from the peer?
No. The out-of-bounds read occurs on every SMC-Rv2 link addition under the affected device condition, regardless of what the peer sends.
How can administrators identify an affected failure?
Kernel memory-safety instrumentation may report a KASAN slab-out-of-bounds read in smc_llc_save_add_link_rkeys during SMC-Rv2 link addition. The report can identify a read of ext->num_rkeys beyond a 72-byte queue-entry allocation.