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 max_recv_sge == 1 there is no shared v2 receive
buffer, and smc_llc_save_add_link_rkeys() takes the v2 extension from 44
bytes past the start of the queue entry's inline message:
ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg + SMC_WR_TX_SIZE);
The entry is a 72-byte allocation and the extension starts at offset 68, so
ext->num_rkeys 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 smc_llc_save_add_link_rkeys+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, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 2.490798] Call Trace:
[ 2.490803] <TASK>
[ 2.490805] dump_stack_lvl+0x53/0x70
[ 2.490810] print_report+0xd0/0x630
[ 2.490828] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 2.490832] ? smc_llc_save_add_link_rkeys+0x333/0x350
[ 2.490834] kasan_report+0xce/0x100
[ 2.490836] ? smc_llc_save_add_link_rkeys+0x333/0x350
[ 2.490837] smc_llc_save_add_link_rkeys+0x333/0x350
[ 2.490839] ? smcr_buf_map_lgr+0x1bf/0x2b0
[ 2.490844] smc_llc_cli_add_link+0xca7/0x1e80
[ 2.490848] ? smc_llc_wait+0x355/0x810
[ 2.490850] ? __pfx_smc_llc_wait+0x10/0x10
[ 2.490851] ? __pfx_smc_llc_cli_add_link+0x10/0x10
[ 2.490853] ? __pfx_autoremove_wake_function+0x10/0x10
[ 2.490863] __smc_connect+0x3f5c/0x4980
[ 2.490873] ? __pfx_kernel_connect+0x10/0x10
[ 2.490888] ? __pfxsmcconnect+0x10/0x10
[ 2.490891] ? release_sock+0x148/0x1d0
[ 2.490894] smc_connect+0x42c/0x580
[ 2.490896] sys_connect+0xfc/0x130
[ 2.490898] ? __pfxsysconnect+0x10/0x10
[ 2.490900] ? handle_mm_fault+0x1a1/0x430
[ 2.490908] x64_sys_connect+0x6d/0xb0
[ 2.490909] ? fpregs_assert_state_consistent+0x56/0xe0
[ 2.490917] do_syscall_64+0xf9/0x540
[ 2.490921] entry_SYSCALL_64_after_hwframe+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 ORIG_RAX: 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] kasan_save_stack+0x33/0x60
[ 2.499860] kasan_save_track+0x14/0x30
[ 2.500026] __kasan_kmalloc+0x8f/0xa0
[ 2.500190] __kmalloc_cache_noprof+0x158/0x370
[ 2.500393] smc_llc_enqueue+0x72/0x560
[ 2.500559] smc_wr_rx_tasklet_fn+0x474/0xa80
[ 2.500747] tasklet_action_common+0x20f/0x8a0
[ 2.500945] handle_softirqs+0x18e/0x590
[ 2.501115] do_softirq+0x3b/0x60
[ 2.501266] __local_bh_enable_ip+0x61/0x70
[ 2.501446] __alloc_skb+0x732/0x890
[ 2.501604] rxe_init_packet+0x16b/0x4f0
[ 2.501783] prepare_ack_packet+0xb8/0x830
[ 2.501962] rxe_receiver+0x495/0x96e0
[ 2.502125] do_work+0x144/0x470
[ 2.502269] process_one_work+0x633/0x1030
[ 2.502450] worker_thread+0x45b/0xd10
[ 2.50261
---truncated---
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - The OOB is reached from SMC-Rv2 LLC ADD_LINK and DELETE_RKEY handling on the RDMA RX path (smc_wr_rx_tasklet_fn→smc_llc_rx_handler→smc_llc_enqueue). CLC is plain TCP and SMC-Rv2/RoCEv2 LLC is IP-routable (UDP/4791), so a remote peer that can reach an AF_SMC listener drives the path.
AC:L - On SMC-Rv2 links with max_recv_sge==1 (the supported device class this bug exists for), every ADD_LINK reads past the 72-byte qentry regardless of peer contents, and a DELETE_RKEY_V2 with num_rkeys=255 walks up to 255 rkeys off the object; no race or attacker-uncontrollable layout is required.
PR:N - SMC authenticates nothing. smc_create()/smc_listen() enforce no capabilities, and smc_listen_work() runs the CLC/LLC handshake after TCP accept before accept() returns to userspace, so an unauthenticated network peer needs only reachability to the listener.
UI:N - The listen worker is queued automatically from smc_tcp_listen_work() for inbound connections, and DELETE_RKEY is processed in the LLC event worker from RDMA completions; no local user action such as mounting a filesystem or opening a file is required.
S:U - The slab out-of-bounds read and the resulting writes into the link-group rtoken table stay inside the host kernel (kmalloc qentry, lgr->rtokens) and do not cross a VM, IOMMU, or sandbox boundary.
C:H - smc_llc_save_add_link_rkeys() reads ext->num_rkeys 22 bytes past the 72-byte qentry and then walks up to 255 16-byte rt[] entries of adjacent heap; smc_llc_rmt_delete_rkey() similarly out-of-bounds-reads rkey[9..254]. Per kernel CNA guidance a large heap out-of-bounds read is High.
I:H - Those out-of-bounds bytes are passed to smc_rtoken_set() (writes rkey/dma_addr into lgr->rtokens) and smc_rtoken_delete() (clears matching rtokens). Adjacent kmalloc-96 spray lets a peer influence the written values, corrupting RDMA targeting used by ib_post_send.
A:H - KASAN reports slab-out-of-bounds in smc_llc_save_add_link_rkeys on every affected ADD_LINK; a multi-kilobyte walk off a 72-byte object can oops when it hits an unmapped page, and a remote peer can repeat the handshake or DELETE_RKEY at will.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - The OOB is reached from SMC-Rv2 LLC ADD_LINK and DELETE_RKEY handling on the RDMA RX path (smc_wr_rx_tasklet_fn→smc_llc_rx_handler→smc_llc_enqueue). CLC is plain TCP and SMC-Rv2/RoCEv2 LLC is IP-routable (UDP/4791), so a remote peer that can reach an AF_SMC listener drives the path.
AC:L - On SMC-Rv2 links with max_recv_sge==1 (the supported device class this bug exists for), every ADD_LINK reads past the 72-byte qentry regardless of peer contents, and a DELETE_RKEY_V2 with num_rkeys=255 walks up to 255 rkeys off the object; no race or attacker-uncontrollable layout is required.
PR:N - SMC authenticates nothing. smc_create()/smc_listen() enforce no capabilities, and smc_listen_work() runs the CLC/LLC handshake after TCP accept before accept() returns to userspace, so an unauthenticated network peer needs only reachability to the listener.
UI:N - The listen worker is queued automatically from smc_tcp_listen_work() for inbound connections, and DELETE_RKEY is processed in the LLC event worker from RDMA completions; no local user action such as mounting a filesystem or opening a file is required.
S:U - The slab out-of-bounds read and the resulting writes into the link-group rtoken table stay inside the host kernel (kmalloc qentry, lgr->rtokens) and do not cross a VM, IOMMU, or sandbox boundary.
C:H - smc_llc_save_add_link_rkeys() reads ext->num_rkeys 22 bytes past the 72-byte qentry and then walks up to 255 16-byte rt[] entries of adjacent heap; smc_llc_rmt_delete_rkey() similarly out-of-bounds-reads rkey[9..254]. Per kernel CNA guidance a large heap out-of-bounds read is High.
I:H - Those out-of-bounds bytes are passed to smc_rtoken_set() (writes rkey/dma_addr into lgr->rtokens) and smc_rtoken_delete() (clears matching rtokens). Adjacent kmalloc-96 spray lets a peer influence the written values, corrupting RDMA targeting used by ib_post_send.
A:H - KASAN reports slab-out-of-bounds in smc_llc_save_add_link_rkeys on every affected ADD_LINK; a multi-kilobyte walk off a 72-byte object can oops when it hits an unmapped page, and a remote peer can repeat the handshake or DELETE_RKEY at will.
CVSS 3.1