Description

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] ? __pfx___smc_connect+0x10/0x10 [ 2.490891] ? release_sock+0x148/0x1d0 [ 2.490894] smc_connect+0x42c/0x580 [ 2.490896] __sys_connect+0xfc/0x130 [ 2.490898] ? __pfx___sys_connect+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---

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:05.180Z",
  "pubdate": "2026-09-11T20:19:05.180Z",
  "executiveSummary": "A slab-out-of-bounds (OOB) read vulnerability exists in the Linux kernel's SMC-Rv2 (Shared Memory Communications over RDMA) subsystem, specifically within the Link Layer Control (LLC) message processing logic.\nThe vulnerability is triggered during the link addition process when the device configuration specifies 'max_recv_sge == 1', causing the kernel to improperly calculate memory offsets when accessing v2 extensions.\nAn attacker capable of initiating an SMC-Rv2 connection can exploit this flaw to induce an out-of-bounds read, leading to a kernel memory disclosure or a system crash due to a kernel panic.\nThis vulnerability is critical for environments utilizing RDMA-capable network interfaces where SMC-Rv2 is enabled, as it bypasses bounds checks on fixed-size memory allocations.\nSuccessful exploitation requires the victim node to process a crafted or malformed LLC message, which can occur during the negotiation phase of the SMC-Rv2 link establishment.",
  "technicalDetails": "The root cause of the vulnerability is an incorrect memory offset calculation in the function 'smc_llc_save_add_link_rkeys' located in 'net/smc/smc_llc.c'.\nIn the SMC-Rv2 protocol, when a link is being added, the subsystem expects a specific structure format. When the underlying hardware device has 'max_recv_sge == 1', the shared receive buffer logic is bypassed, and the kernel attempts to derive the 'smc_llc_msg_add_link_v2_ext' extension from an offset defined by 'SMC_WR_TX_SIZE' (44 bytes) past the start of the queue entry's inline message.\nThe queue entry is allocated as a 72-byte structure. By calculating the extension starting at an offset of 44 bytes, the code places the 'smc_llc_msg_add_link_v2_ext' header starting at index 44. The 'num_rkeys' field within this structure is located at a 50-byte offset from the start of the extension header, resulting in a cumulative offset of 94 bytes.\nBecause the total allocation size for the entry is only 72 bytes, the access to the 'num_rkeys' field at offset 94 occurs well outside the boundary of the allocated slab memory, leading to the reported KASAN slab-out-of-bounds error.\nThe attack flow proceeds as follows: 1) An attacker initiates an SMC-Rv2 connection with a target system. 2) During the handshake, the initiator triggers the 'smc_llc_cli_add_link' process. 3) The target kernel, upon receiving the LLC message, attempts to parse the v2 extensions. 4) Due to the lack of validation for the entry size relative to the expected extension fields, the kernel performs a read operation at an invalid address. 5) This leads to a KASAN memory access violation and a subsequent kernel panic, effectively creating a Denial of Service (DoS) condition.\nThe vulnerability highlights a failure in validating input sizes against fixed-length buffer allocations before casting memory regions to structured types. This allows the kernel to operate on adjacent heap memory, potentially exposing sensitive kernel pointers or data residing in the slab cache."
}