From: Dragos Tatulea <dtatulea@nvidia.com>
To: Binbin Deng <18983559317@163.com>,
saeedm@nvidia.com, leon@kernel.org, tariqt@nvidia.com,
mbloch@nvidia.com, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] net/mlx5e: IPoIB: Fix race in QPN to netdev mapping
Date: Mon, 2 Nov 2026 11:19:42 +0100 [thread overview]
Message-ID: <60624007-533c-4180-85fd-b8d234bd47b4@nvidia.com> (raw)
In-Reply-To: <20261102074107.32859-1-18983559317@163.com>
On 02.11.26 08:41, Binbin Deng wrote:
> The QPN-to-netdev hash table is protected by ht_lock, but the NAPI lookup
> path traverses and dereferences nodes without taking that lock. A child
> interface teardown can therefore remove and free the node while the parent
> RQ is still processing completions for that child:
>
> CPU0 CPU1
> mlx5i_pkey_get_netdev()
> node = mlx5i_find_qpn_to_netdev_node()
> mlx5i_pkey_del_qpn()
> node = mlx5i_find_qpn_to_netdev_node()
> spin_lock_bh(&ht->ht_lock)
> hlist_del_init(&node->hlist)
> spin_unlock_bh(&ht->ht_lock)
> kfree(node)
> read node->netdev or node->hlist.next
>
> At that point CPU0 is reading freed memory. The race is reachable when a
> PKEY child interface goes down while its completions are still queued on
> the shared parent RQ; this is the same lifetime case already described by
> the RX path comment. It can lead to a KASAN use-after-free, corruption of
> the RX path, or a panic.
>
> Take ht_lock around hash lookups, and keep the deletion lookup and unlink
> in one critical section. The NAPI path copies the netdev pointer while
> the lock prevents the mapping node from being freed.
>
> Found during a static-analysis-assisted audit: candidate sites were
> surfaced by a Coccinelle rule, and the reader/writer paths were
> confirmed by deep code inspection. Due to a lack of hardware
> infrastructure, the issue was not observed at runtime.
>
> Fixes: 7e7f4780c340 ("net/mlx5e: IPoIB, Use hash-table to map between QPN to child netdev")
> Assisted-by: Coccinelle
> Signed-off-by: Binbin Deng <18983559317@163.com>
Already WIP by Prathamesh:
https://lore.kernel.org/all/20261031225749.14214-1-prathameshdeshpande7@gmail.com/
Thanks,
Dragos
prev parent reply other threads:[~2026-11-02 10:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 7:41 Binbin Deng
2026-11-02 10:19 ` Dragos Tatulea [this message]
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=60624007-533c-4180-85fd-b8d234bd47b4@nvidia.com \
--to=dtatulea@nvidia.com \
--cc=18983559317@163.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/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
all inboxes | Powered by JetHome®