Description

In the Linux kernel, the following vulnerability has been resolved: net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() 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---

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:04.520Z",
  "pubdate": "2026-09-11T20:19:04.520Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's Shared Memory Communications (SMC) implementation within the net/smc module.\nThe flaw originates from an improper lifecycle management of LLC (Logical Link Control) queue entries during link addition procedures in the smc_llc_srv_add_link() function.\nAn attacker capable of triggering specific SMC link management operations can cause the kernel to access memory that has already been deallocated via kfree(), leading to a potential system crash or arbitrary code execution.\nThe vulnerability represents a significant stability and security risk, as it allows local attackers to trigger a kernel panic or potentially escalate privileges by manipulating memory states during the processing of link management messages.\nExploitation requires the ability to interact with the SMC subsystem, often necessitating local access or specific network configurations that utilize the SMC protocol.",
  "technicalDetails": "The root cause of this use-after-free vulnerability is located in the function smc_llc_srv_add_link() within the net/smc/smc_llc.c source file. The kernel maintains a local pointer 'add_llc' that references a structure within a queue entry ('qentry'). During the execution flow, the function performs an operation that relies on the data stored in this queue entry. Specifically, it calls smc_llc_save_add_link_info(link_new, add_llc) followed by smc_llc_flow_qentry_del(&lgr->llc_flow_lcl).\nThe function smc_llc_flow_qentry_del() invokes kfree() on the 'qentry' object. However, the subsequent logic in smc_llc_srv_add_link() continues to access the 'add_llc' pointer when invoking smc_llc_save_add_link_rkeys(link, link_new, llc_msg) if a shared v2 receive buffer is not present. Because 'add_llc' points directly into the memory of the previously freed 'qentry', the subsequent read operation performs a use-after-free access.\nThe attack flow involves initiating an SMC connection establishment process where the link synchronization requires the processing of LLC 'add link' messages. By forcing the system into a state where it lacks a shared v2 receive buffer (e.g., using specific hardware configurations or forced receive SGE limitations), the code execution path is forced into the vulnerable branch. The attacker triggers the kernel worker thread (smc_listen_work) to process the crafted LLC flow, which leads to the immediate deallocation of the memory while the pointer is still actively held by the execution context. When the function later attempts to read this memory address to save remote keys, the kernel detects a violation of memory integrity if KASAN is enabled, or executes an illegal memory access otherwise.\nThis vulnerability is particularly sensitive because it occurs within the core SMC state machine handling asynchronous tasks. The impact extends beyond simple denial-of-service, as memory corruption in the kernel heap can potentially be leveraged to overwrite function pointers or other critical structures if the slab allocator reallocates the freed memory chunk before the use-after-free occurs. The vulnerability affects the SMC protocol implementation and is exposed via socket-based communications, primarily impacting systems with high-performance networking offloads."
}