[PATCH net 0/2] net/mlx5e: fix NULL derefs when RX queue mapping outlives channel reconfig

[PATCH net 0/2] net/mlx5e: fix NULL derefs when RX queue mapping outlives channel reconfig

[Rishikesh Jethwani]

Hi all,

This series fixes two related NULL derefs in mlx5e's kTLS RX offload that
surface when a channel-count reduction (e.g. ethtool -L combined N) leaves
sockets carrying a queue index that is no longer valid

Patch 1: reject stale RX queue mapping on RX offload setup
Patch 2: guard RX resync against stale channel index

Not addressed in this series:

- Torn reads of `priv->channels` during the struct-copy publish in
  `mlx5e_switch_priv_channels()`. A reader on another CPU can still
  briefly observe `{new c, old num}`, so bounds-checking against a
  stale `num` can pass while dereferencing the new smaller array.
  Closing that window likely needs proper synchronization,
  such as RCU pointer, which is a larger change and better handled
  in a separate series.
    
- Re-homing existing offloaded sockets across a channel shrink so
  `priv_rx->rxq` remains valid. Patch 2 makes this failure mode graceful
  by preventing the dereference, but the offload remains functionally
  broken until the socket is torn down and re-added. That looks like a
  broader design question for the mlx5 maintainers.

Rishikesh Jethwani (2):
  net/mlx5e: kTLS: reject stale RX queue mapping on RX offload setup
  net/mlx5e: kTLS: guard RX resync against stale channel index

 .../mellanox/mlx5/core/en_accel/ktls_rx.c     | 24 ++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

-- 
2.25.1

[PATCH 1/2] net/mlx5e: kTLS: reject stale RX queue mapping on RX offload setup

[Rishikesh Jethwani]

mlx5e_ktls_sk_get_rxq() treats only the -1 sentinel from
sk_rx_queue_get() as special and returns all other values unchanged.

After 'ethtool -L <dev> combined N' reduces the number of channels, a
socket can retain an sk_rx_queue_mapping from the previous
configuration that is no longer valid for the current
priv->channels.num. If TLS RX offload is then enabled for that socket,
mlx5e_ktls_add_rx() uses the stale queue index and can access a
channel outside the current array.

Preserve the existing -1 -> 0 fallback for sockets that do not yet
have a recorded RX queue, but reject queue indices that are outside
the current channel range and fail setup with -EINVAL instead. Wire
the failure through the existing err_create_tir unwind so resources
allocated earlier in mlx5e_ktls_add_rx() are released cleanly.

This addresses stale queue mappings during RX offload setup. Existing
offloaded sockets whose channel disappears after reconfiguration are
handled separately in the resync path.

Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
Link: https://lore.kernel.org/netdev/20260627210635.89769-1-nils.juenemann@gmail.com/
Reported-by: Nils Juenemann <nils.juenemann@gmail.com>
Tested-by: Nils Juenemann <nils.juenemann@gmail.com>
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
 .../ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c  | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
index bca45679e201..232e998a8f24 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
@@ -620,12 +620,15 @@ void mlx5e_ktls_handle_ctx_completion(struct mlx5e_icosq_wqe_info *wi)
 	queue_work(rule->priv->tls->rx_wq, &rule->work);
 }
 
-static int mlx5e_ktls_sk_get_rxq(struct sock *sk)
+static int mlx5e_ktls_sk_get_rxq(struct mlx5e_priv *priv, struct sock *sk)
 {
 	int rxq = sk_rx_queue_get(sk);
 
 	if (unlikely(rxq == -1))
-		rxq = 0;
+		return 0;
+
+	if (unlikely(rxq >= priv->channels.num))
+		return -EINVAL;
 
 	return rxq;
 }
@@ -673,7 +676,11 @@ int mlx5e_ktls_add_rx(struct net_device *netdev, struct sock *sk,
 	INIT_LIST_HEAD(&priv_rx->list);
 	spin_lock_init(&priv_rx->lock);
 
-	rxq = mlx5e_ktls_sk_get_rxq(sk);
+	rxq = mlx5e_ktls_sk_get_rxq(priv, sk);
+	if (unlikely(rxq < 0)) {
+		err = rxq;
+		goto err_create_tir;
+	}
 	priv_rx->rxq = rxq;
 	priv_rx->sk = sk;
 
-- 
2.25.1

[PATCH 2/2] net/mlx5e: kTLS: guard RX resync against stale channel index

[Rishikesh Jethwani]

An RX offloaded socket stores its channel index in priv_rx->rxq when
offload is enabled. If the channel count later shrinks, e.g. via
'ethtool -L <dev> combined N', existing offloaded sockets can still
carry a queue index from the old channel layout.

The kTLS RX resync paths index priv->channels.c[priv_rx->rxq] directly
in both resync_handle_work() and mlx5e_ktls_rx_resync(). After channel
reduction, a stale priv_rx->rxq can be out of range for the current
priv->channels.num and lead to invalid channel access.

Guard both resync sites with a bounds check on priv_rx->rxq and bail out
gracefully when the stored queue no longer exists. Account the skipped
request and, in the workqueue path, cancel the async resync request and
drop the reference taken when the work item was queued.

This complements the previous add-path fix, which rejects stale RXQ
mappings during offload setup. Existing offloaded sockets still need
protection in the resync callbacks after a channel-count reduction.

Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
Link: https://lore.kernel.org/netdev/20260627210635.89769-1-nils.juenemann@gmail.com/
Reported-by: Nils Juenemann <nils.juenemann@gmail.com>
Tested-by: Nils Juenemann <nils.juenemann@gmail.com>
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
 .../ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c    | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
index 232e998a8f24..c0676148a36e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
@@ -343,6 +343,13 @@ static void resync_handle_work(struct work_struct *work)
 		return;
 	}
 
+	if (unlikely(priv_rx->rxq >= resync->priv->channels.num)) {
+		priv_rx->rq_stats->tls_resync_req_skip++;
+		tls_offload_rx_resync_async_request_cancel(&resync->core);
+		mlx5e_ktls_priv_rx_put(priv_rx);
+		return;
+	}
+
 	c = resync->priv->channels.c[priv_rx->rxq];
 	sq = c->async_icosq;
 
@@ -568,6 +575,10 @@ void mlx5e_ktls_rx_resync(struct net_device *netdev, struct sock *sk,
 	resync->seq = seq;
 
 	priv = netdev_priv(netdev);
+	if (unlikely(priv_rx->rxq >= priv->channels.num)) {
+		priv_rx->rq_stats->tls_resync_req_skip++;
+		return;
+	}
 	c = priv->channels.c[priv_rx->rxq];
 
 	resync_handle_seq_match(priv_rx, c);
-- 
2.25.1

Re: [PATCH 1/2] net/mlx5e: kTLS: reject stale RX queue mapping on RX offload setup

[Tariq Toukan]

On 15/07/2026 1:29, Rishikesh Jethwani wrote:
> mlx5e_ktls_sk_get_rxq() treats only the -1 sentinel from
> sk_rx_queue_get() as special and returns all other values unchanged.
> 
> After 'ethtool -L <dev> combined N' reduces the number of channels, a
> socket can retain an sk_rx_queue_mapping from the previous
> configuration that is no longer valid for the current
> priv->channels.num. If TLS RX offload is then enabled for that socket,
> mlx5e_ktls_add_rx() uses the stale queue index and can access a
> channel outside the current array.
> 
> Preserve the existing -1 -> 0 fallback for sockets that do not yet
> have a recorded RX queue, but reject queue indices that are outside
> the current channel range and fail setup with -EINVAL instead. Wire
> the failure through the existing err_create_tir unwind so resources
> allocated earlier in mlx5e_ktls_add_rx() are released cleanly.
> 
> This addresses stale queue mappings during RX offload setup. Existing
> offloaded sockets whose channel disappears after reconfiguration are
> handled separately in the resync path.
> 
> Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
> Link: https://lore.kernel.org/netdev/20260627210635.89769-1-nils.juenemann@gmail.com/
> Reported-by: Nils Juenemann <nils.juenemann@gmail.com>
> Tested-by: Nils Juenemann <nils.juenemann@gmail.com>
> Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
> ---

Thanks for your patch.

>   .../ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c  | 13 ++++++++++---
>   1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
> index bca45679e201..232e998a8f24 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
> @@ -620,12 +620,15 @@ void mlx5e_ktls_handle_ctx_completion(struct mlx5e_icosq_wqe_info *wi)
>   	queue_work(rule->priv->tls->rx_wq, &rule->work);
>   }
>   
> -static int mlx5e_ktls_sk_get_rxq(struct sock *sk)
> +static int mlx5e_ktls_sk_get_rxq(struct mlx5e_priv *priv, struct sock *sk)
>   {
>   	int rxq = sk_rx_queue_get(sk);
>   
>   	if (unlikely(rxq == -1))
> -		rxq = 0;
> +		return 0;
> +
> +	if (unlikely(rxq >= priv->channels.num))
> +		return -EINVAL;
>   
>   	return rxq;
>   }
> @@ -673,7 +676,11 @@ int mlx5e_ktls_add_rx(struct net_device *netdev, struct sock *sk,
>   	INIT_LIST_HEAD(&priv_rx->list);
>   	spin_lock_init(&priv_rx->lock);
>   
> -	rxq = mlx5e_ktls_sk_get_rxq(sk);
> +	rxq = mlx5e_ktls_sk_get_rxq(priv, sk);
> +	if (unlikely(rxq < 0)) {
> +		err = rxq;
> +		goto err_create_tir;
> +	}

This is not bullet proof.
Here you just shorten the interval and reduce the probability of the bug.

As this flow is not protected by the state_lock, it is still possible to 
have the num of channels changing after your read above.

IMO, this can't be resolved without holding the mutex here.
I'm doing further research to come up with the proper solution.

>   	priv_rx->rxq = rxq;
>   	priv_rx->sk = sk;
>   

Re: [PATCH 1/2] net/mlx5e: kTLS: reject stale RX queue mapping on RX offload setup

[Tariq Toukan]

On 16/07/2026 11:35, Tariq Toukan wrote:
> 
> 
> On 15/07/2026 1:29, Rishikesh Jethwani wrote:
>> mlx5e_ktls_sk_get_rxq() treats only the -1 sentinel from
>> sk_rx_queue_get() as special and returns all other values unchanged.
>>
>> After 'ethtool -L <dev> combined N' reduces the number of channels, a
>> socket can retain an sk_rx_queue_mapping from the previous
>> configuration that is no longer valid for the current
>> priv->channels.num. If TLS RX offload is then enabled for that socket,
>> mlx5e_ktls_add_rx() uses the stale queue index and can access a
>> channel outside the current array.
>>
>> Preserve the existing -1 -> 0 fallback for sockets that do not yet
>> have a recorded RX queue, but reject queue indices that are outside
>> the current channel range and fail setup with -EINVAL instead. Wire
>> the failure through the existing err_create_tir unwind so resources
>> allocated earlier in mlx5e_ktls_add_rx() are released cleanly.
>>
>> This addresses stale queue mappings during RX offload setup. Existing
>> offloaded sockets whose channel disappears after reconfiguration are
>> handled separately in the resync path.
>>
>> Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
>> Link: https://lore.kernel.org/netdev/20260627210635.89769-1- 
>> nils.juenemann@gmail.com/
>> Reported-by: Nils Juenemann <nils.juenemann@gmail.com>
>> Tested-by: Nils Juenemann <nils.juenemann@gmail.com>
>> Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
>> ---
> 
> Thanks for your patch.
> 
>>   .../ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c  | 13 ++++++++++---
>>   1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ 
>> ktls_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
>> index bca45679e201..232e998a8f24 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
>> @@ -620,12 +620,15 @@ void mlx5e_ktls_handle_ctx_completion(struct 
>> mlx5e_icosq_wqe_info *wi)
>>       queue_work(rule->priv->tls->rx_wq, &rule->work);
>>   }
>> -static int mlx5e_ktls_sk_get_rxq(struct sock *sk)
>> +static int mlx5e_ktls_sk_get_rxq(struct mlx5e_priv *priv, struct sock 
>> *sk)
>>   {
>>       int rxq = sk_rx_queue_get(sk);
>>       if (unlikely(rxq == -1))
>> -        rxq = 0;
>> +        return 0;
>> +
>> +    if (unlikely(rxq >= priv->channels.num))
>> +        return -EINVAL;
>>       return rxq;
>>   }
>> @@ -673,7 +676,11 @@ int mlx5e_ktls_add_rx(struct net_device *netdev, 
>> struct sock *sk,
>>       INIT_LIST_HEAD(&priv_rx->list);
>>       spin_lock_init(&priv_rx->lock);
>> -    rxq = mlx5e_ktls_sk_get_rxq(sk);
>> +    rxq = mlx5e_ktls_sk_get_rxq(priv, sk);
>> +    if (unlikely(rxq < 0)) {
>> +        err = rxq;
>> +        goto err_create_tir;
>> +    }
> 
> This is not bullet proof.
> Here you just shorten the interval and reduce the probability of the bug.
> 
> As this flow is not protected by the state_lock, it is still possible to 
> have the num of channels changing after your read above.
> 
> IMO, this can't be resolved without holding the mutex here.
> I'm doing further research to come up with the proper solution.
> 
Please note we were not CCed on this email.
Let's make sure we're not missed on future ones.