* Re: [PATCH v2] RDMA/core: Fix memory leak in __ib_create_cq() on invalid cqe
From: Kalesh Anakkur Purayil @ 2026-06-25 7:32 UTC (permalink / raw)
To: Chenguang Zhao
Cc: jgg, leon, edwards, mbloch, michaelgur, msanalla, ohartoov, jiri,
linux-rdma
In-Reply-To: <20260625020148.224537-1-zhaochenguang@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Thu, Jun 25, 2026 at 7:33 AM Chenguang Zhao <zhaochenguang@kylinos.cn> wrote:
>
> Move the zero CQE validation before rdma_zalloc_drv_obj() to avoid
> leaking the CQ object when returning -EINVAL.
>
> Fixes: a2917582887a ("RDMA/core: Reject zero CQE count")
> Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
LGTM,
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
--
Regards,
Kalesh AP
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5509 bytes --]
^ permalink raw reply
* Re: [PATCH net] net/smc: avoid recursive sk_callback_lock in listen data_ready
From: Sidraya Jayagond @ 2026-06-25 8:32 UTC (permalink / raw)
To: Runyu Xiao, D. Wythe, Dust Li, Wenjia Zhang, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Mahanta Jambigi, Tony Lu, Wen Gu, Simon Horman, Karsten Graul,
linux-rdma, linux-s390, netdev, linux-kernel, jianhao.xu, stable
In-Reply-To: <20260617152855.1039151-1-runyu.xiao@seu.edu.cn>
On 17/06/26 8:58 pm, Runyu Xiao wrote:
> smc_listen() installs smc_clcsock_data_ready() as the underlying TCP
> listen socket's sk_data_ready callback. smc_clcsock_data_ready() then
> immediately takes sk_callback_lock before looking up the SMC listener and
> queuing smc_tcp_listen_work().
>
> That is unsafe once the TCP listen socket is leaving TCP_LISTEN. The TCP
> close/flush path can run the installed sk_data_ready callback with
> sk_callback_lock already held, so entering smc_clcsock_data_ready() again
> tries to take the same rwlock recursively in the same thread. The nvmet
> TCP listener had to make the same state check before taking
> sk_callback_lock for this reason.
>
> This issue was found by our static analysis tool and then manually
> reviewed against the current tree.
>
> The grounded PoC kept the SMC listen callback installation path:
>
> smc_listen()
> smc_clcsock_replace_cb()
> sk_data_ready = smc_clcsock_data_ready()
>
> It then modeled the close/flush carrier that invokes the installed
> sk_data_ready callback while sk_callback_lock is already held. Lockdep
> reported the same-thread recursive acquisition:
>
> WARNING: possible recursive locking detected
> smc_clcsock_data_ready+0xa/0x4d [vuln_msv]
> smc_close_flush_work+0x1f/0x30 [vuln_msv]
> *** DEADLOCK ***
>
> Return before taking sk_callback_lock when the underlying TCP socket is no
> longer in TCP_LISTEN. In that state there is no listen accept work to
> queue for SMC, and avoiding the callback lock mirrors the fix used by the
> TCP nvmet listener.
>
> Fixes: 0558226cebee ("net/smc: Fix slab-out-of-bounds issue in fallback")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> ---
> net/smc/af_smc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 6421c2e1c84d..1af4e3c333ff 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -2631,6 +2631,9 @@ static void smc_clcsock_data_ready(struct sock *listen_clcsock)
> {
> struct smc_sock *lsmc;
>
> + if (READ_ONCE(listen_clcsock->sk_state) != TCP_LISTEN)
> + return;
> +
In smc_close_active(), the TCP socket remains in TCP_LISTEN state while
holding write_lock_bh(&smc->clcsock->sk->sk_callback_lock);. The patch's
state check would pass during this window, not preventing the recursive
lock scenario.
It's unclear whether it fully prevents the recursive locking scenario
described in the commit message for the specific code path in
smc_close_active().
Could you come up with exact deadlock scenario and how the patch
addresses it?
> read_lock_bh(&listen_clcsock->sk_callback_lock);
> lsmc = smc_clcsock_user_data(listen_clcsock);
> if (!lsmc)
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox