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: 12+ 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-12 23:20 ` sashiko-bot
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-12 23:20 ` sashiko-bot
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-12 23:20 ` sashiko-bot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.