From: Sidraya Jayagond <sidraya@linux.ibm.com>
To: Yehyeong Lee <yhlee@isslab.korea.ac.kr>,
alibuda@linux.alibaba.com, dust.li@linux.alibaba.com,
wenjia@linux.ibm.com, kuba@kernel.org, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com
Cc: leitao@debian.org, horms@kernel.org, mjambigi@linux.ibm.com,
tonylu@linux.alibaba.com, guwen@linux.alibaba.com,
guangguan.wang@linux.alibaba.com, kees@kernel.org,
gustavoars@kernel.org, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH net v6 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link()
Date: Tue, 18 Aug 2026 20:59:15 +0530 [thread overview]
Message-ID: <f0877836-771e-4f87-bf7b-adc7053d8446@linux.ibm.com> (raw)
In-Reply-To: <20260811231902.47089-2-yhlee@isslab.korea.ac.kr>
On 12/08/26 4:49 am, Yehyeong Lee wrote:
> 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.534078] process_one_work+0x633/0x1030
> [ 2.534257] worker_thread+0x45b/0xd10
> [ 2.534424] kthread+0x2c6/0x3b0
> [ 2.534569] ret_from_fork+0x36e/0x5a0
> [ 2.534737] ret_from_fork_asm+0x1a/0x30
> [ 2.534907]
> [ 2.534980] Freed by task 11:
> [ 2.535112] kasan_save_stack+0x33/0x60
> [ 2.535279] kasan_save_track+0x14/0x30
> [ 2.535444] kasan_save_free_info+0x3b/0x60
> [ 2.535625] __kasan_slab_free+0x43/0x70
> [ 2.535798] kfree+0x121/0x380
> [ 2.535935] smc_llc_srv_add_link+0x9a8/0x1e50
> [ 2.536128] smc_listen_work+0x489e/0x4d00
> [ 2.536305] process_one_work+0x633/0x1030
> [ 2.536482] worker_thread+0x45b/0xd10
> [ 2.536652] kthread+0x2c6/0x3b0
> [ 2.536794] ret_from_fork+0x36e/0x5a0
> [ 2.536958] ret_from_fork_asm+0x1a/0x30
> [ 2.537133]
> [ 2.537205] The buggy address belongs to the object at ffff888005219480
> [ 2.537205] which belongs to the cache kmalloc-96 of size 96
> [ 2.537719] The buggy address is located 94 bytes inside of
> [ 2.537719] freed 96-byte region [ffff888005219480, ffff8880052194e0)
> [ 2.538216]
> [ 2.538289] The buggy address belongs to the physical page:
> [ 2.538524] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5219
> [ 2.538857] flags: 0x100000000000000(node=0|zone=1)
> [ 2.539066] page_type: f5(slab)
> [ 2.539210] raw: 0100000000000000 ffff888001041280 dead000000000122 0000000000000000
> [ 2.539534] raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000
> [ 2.539863] page dumped because: kasan: bad access detected
> [ 2.540098]
> [ 2.540170] Memory state around the buggy address:
> [ 2.540379] ffff888005219380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 2.540684] ffff888005219400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 2.540988] >ffff888005219480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> [ 2.541291] ^
> [ 2.541548] ffff888005219500: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
> [ 2.541857] ffff888005219580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
>
> The offset is past the 72-byte queue entry because the out-of-bounds read
> fixed by the next patch is on the same line; what this patch removes is the
> free at smc_llc_srv_add_link+0x9a8 happening before the read at +0xaa2.
>
> Detach the entry instead of freeing it there, and free it at the single
> exit label. The reject path has to detach as well, otherwise it would be
> freed twice.
>
> This changes only the lifetime of the entry. The same read still runs past
> its end until the next two patches bound it, so a backport wants all three.
>
> Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
> ---
> Changes since v5: return through the existing exit label.
>
> net/smc/smc_llc.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
> index 954b2ff1815c..055a03eee5b5 100644
> --- a/net/smc/smc_llc.c
> +++ b/net/smc/smc_llc.c
> @@ -1481,7 +1481,7 @@ int smc_llc_srv_add_link(struct smc_link *link,
> }
> add_llc = &qentry->msg.add_link;
> if (add_llc->hd.flags & SMC_LLC_FLAG_ADD_LNK_REJ) {
> - smc_llc_flow_qentry_del(&lgr->llc_flow_lcl);
> + smc_llc_flow_qentry_clr(&lgr->llc_flow_lcl);
> rc = -ENOLINK;
> goto out_err;
> }
> @@ -1492,7 +1492,8 @@ int smc_llc_srv_add_link(struct smc_link *link,
> lgr_new_t = SMC_LGR_ASYMMETRIC_PEER;
> }
> smc_llc_save_add_link_info(link_new, add_llc);
> - smc_llc_flow_qentry_del(&lgr->llc_flow_lcl);
> + /* add_llc still points into qentry, so only detach it here */
> + smc_llc_flow_qentry_clr(&lgr->llc_flow_lcl);
>
> rc = smc_ib_ready_link(link_new);
> if (rc)
> @@ -1512,14 +1513,14 @@ int smc_llc_srv_add_link(struct smc_link *link,
> rc = smc_llc_srv_conf_link(link, link_new, lgr_new_t);
> if (rc)
> goto out_err;
> - kfree(ini);
> - return 0;
> + goto out;
> out_err:
> if (link_new) {
> link_new->state = SMC_LNK_INACTIVE;
> smcr_link_clear(link_new, false);
> }
> out:
> + kfree(qentry);
> kfree(ini);
> if (send_req_add_link_resp)
> smc_llc_send_req_add_link_response(req_qentry);
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
next prev parent reply other threads:[~2026-08-18 15:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 23:18 [PATCH net v6 0/3] net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing Yehyeong Lee
2026-08-11 23:19 ` [PATCH net v6 1/3] net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() Yehyeong Lee
2026-08-18 15:29 ` Sidraya Jayagond [this message]
2026-08-11 23:19 ` [PATCH net v6 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages Yehyeong Lee
2026-08-18 15:32 ` Sidraya Jayagond
2026-08-11 23:19 ` [PATCH net v6 3/3] net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry Yehyeong Lee
2026-08-18 15:37 ` Sidraya Jayagond
2026-08-13 6:15 ` [PATCH net v6 0/3] net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing Yehyeong Lee
2026-08-17 18:29 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f0877836-771e-4f87-bf7b-adc7053d8446@linux.ibm.com \
--to=sidraya@linux.ibm.com \
--cc=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=dust.li@linux.alibaba.com \
--cc=edumazet@google.com \
--cc=guangguan.wang@linux.alibaba.com \
--cc=gustavoars@kernel.org \
--cc=guwen@linux.alibaba.com \
--cc=horms@kernel.org \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjambigi@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tonylu@linux.alibaba.com \
--cc=wenjia@linux.ibm.com \
--cc=yhlee@isslab.korea.ac.kr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox