* [PATCH v1] net/mlx5e: IPoIB: Fix race in QPN to netdev mapping
@ 2026-11-02 7:41 Binbin Deng
2026-11-02 10:19 ` Dragos Tatulea
0 siblings, 1 reply; 2+ messages in thread
From: Binbin Deng @ 2026-11-02 7:41 UTC (permalink / raw)
To: saeedm, leon, tariqt, mbloch, andrew+netdev, davem, edumazet,
kuba, pabeni
Cc: netdev, linux-rdma, linux-kernel, Binbin Deng
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>
---
drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib_vlan.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib_vlan.c b/drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib_vlan.c
index 4120afd097c3..91b203c6d603 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib_vlan.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib_vlan.c
@@ -109,13 +109,14 @@ int mlx5i_pkey_del_qpn(struct net_device *netdev, u32 qpn)
struct mlx5i_pkey_qpn_ht *ht = ipriv->qpn_htbl;
struct qpn_to_netdev *node;
+ spin_lock_bh(&ht->ht_lock);
node = mlx5i_find_qpn_to_netdev_node(ht->buckets, qpn);
if (!node) {
mlx5_core_warn(epriv->mdev, "QPN to netdev delete from HT failed\n");
+ spin_unlock_bh(&ht->ht_lock);
return -EINVAL;
}
- spin_lock_bh(&ht->ht_lock);
hlist_del_init(&node->hlist);
spin_unlock_bh(&ht->ht_lock);
kfree(node);
@@ -128,10 +129,12 @@ struct net_device *mlx5i_pkey_get_netdev(struct net_device *netdev, u32 qpn)
struct mlx5i_priv *ipriv = netdev_priv(netdev);
struct qpn_to_netdev *node;
+ spin_lock_bh(&ipriv->qpn_htbl->ht_lock);
node = mlx5i_find_qpn_to_netdev_node(ipriv->qpn_htbl->buckets, qpn);
if (!node)
return NULL;
-
+ spin_unlock_bh(&ipriv->qpn_htbl->ht_lock);
+
return node->netdev;
}
--
2.43.0
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v1] net/mlx5e: IPoIB: Fix race in QPN to netdev mapping
2026-11-02 7:41 [PATCH v1] net/mlx5e: IPoIB: Fix race in QPN to netdev mapping Binbin Deng
@ 2026-11-02 10:19 ` Dragos Tatulea
0 siblings, 0 replies; 2+ messages in thread
From: Dragos Tatulea @ 2026-11-02 10:19 UTC (permalink / raw)
To: Binbin Deng, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni
Cc: netdev, linux-rdma, linux-kernel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-11-02 10:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-02 7:41 [PATCH v1] net/mlx5e: IPoIB: Fix race in QPN to netdev mapping Binbin Deng
2026-11-02 10:19 ` Dragos Tatulea
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®