[PATCH v2 net] octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup

[PATCH v2 net] octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup

[Ratheesh Kannoth]

From: Suman Ghosh <sumang@marvell.com>

af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is
allocated during PF/VF probe. Representors and other non-AF_XDP paths
leave the pointer NULL, but several call sites used test_bit() on it
unconditionally.

Switching to devlink eswitch mode creates representors and runs
otx2_init_hw_resources(), which reaches otx2_pool_aq_init() and oopses
when dereferencing the NULL bitmap. Add NULL checks before every
af_xdp_zc_qidx test_bit() use in the RSS, ethtool, XSK, and pool init
paths.

Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support")
Signed-off-by: Suman Ghosh <sumang@marvell.com>
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>

---
v1 -> v2: Addressed sashiko comments
	https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260820090533.2681578-1-rkannoth%40marvell.com
---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c  | 6 ++++--
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 3 ++-
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c     | 3 ++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index ca73a94db794..175992188c18 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -333,7 +333,8 @@ int otx2_set_rss_table(struct otx2_nic *pfvf, int ctx_id, const u32 *ind_tbl)
 	/* Get memory to put this msg */
 	for (idx = 0; idx < rss->rss_size; idx++) {
 		/* Ignore the queue if AF_XDP zero copy is enabled */
-		if (test_bit(ind_tbl[idx], pfvf->af_xdp_zc_qidx))
+		if (pfvf->af_xdp_zc_qidx &&
+		    test_bit(ind_tbl[idx], pfvf->af_xdp_zc_qidx))
 			continue;
 
 		aq = otx2_mbox_alloc_msg_nix_aq_enq(mbox);
@@ -1509,7 +1510,8 @@ int otx2_pool_aq_init(struct otx2_nic *pfvf, u16 pool_id,
 	if (type != AURA_NIX_RQ)
 		return 0;
 
-	if (!test_bit(pool_id, pfvf->af_xdp_zc_qidx)) {
+	if (!pfvf->af_xdp_zc_qidx ||
+	    !test_bit(pool_id, pfvf->af_xdp_zc_qidx)) {
 		pp_params.order = get_order(buf_size);
 		pp_params.flags = PP_FLAG_DMA_MAP;
 		pp_params.pool_size = min(OTX2_PAGE_POOL_SZ, numptrs);
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
index a0340f3422bf..9bee1b91eeaa 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
@@ -939,7 +939,8 @@ static int otx2_get_rxfh(struct net_device *dev,
 
 	for (idx = 0; idx < rss->rss_size; idx++) {
 		/* Ignore if the rx queue is AF_XDP zero copy enabled */
-		if (test_bit(rss->ind_tbl[idx], pfvf->af_xdp_zc_qidx))
+		if (pfvf->af_xdp_zc_qidx &&
+		    test_bit(rss->ind_tbl[idx], pfvf->af_xdp_zc_qidx))
 			continue;
 		indir[idx] = rss->ind_tbl[idx];
 	}
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c
index 7d67b4cbaf71..0e8a6a6486c4 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c
@@ -193,7 +193,8 @@ int otx2_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags)
 
 void otx2_attach_xsk_buff(struct otx2_nic *pfvf, struct otx2_snd_queue *sq, int qidx)
 {
-	if (test_bit(qidx, pfvf->af_xdp_zc_qidx))
+	if (pfvf->af_xdp_zc_qidx &&
+	    test_bit(qidx, pfvf->af_xdp_zc_qidx))
 		sq->xsk_pool = xsk_get_pool_from_qid(pfvf->netdev, qidx);
 }
 
-- 
2.43.0

Re: [PATCH v2 net] octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch adds NULL checks before test_bit() but misses set_bit() and clear_bit() on af_xdp_zc_qidx, leaving a probe race condition that leads to a NULL pointer dereference.
- [High] NAPI is not disabled during XSK pool setup, causing a data race on the completion queue.
- [High] Incorrect conditional check for XDP queues when attaching XSK buffer pools leads to misconfiguration and breaks zero-copy TX.
--

--- Patch [1]: [PATCH v2 net] octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup ---
commit 5f1a1574e7a51207651e67a7a10d7e4ef025c443
Author: Suman Ghosh <sumang@marvell.com>

octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup

af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is
allocated during PF/VF probe. Representors and other non-AF_XDP paths
leave the pointer NULL, but several call sites used test_bit() on it
unconditionally.

Switching to devlink eswitch mode creates representors and runs
otx2_init_hw_resources(), which reaches otx2_pool_aq_init() and oopses
when dereferencing the NULL bitmap. Add NULL checks before every
af_xdp_zc_qidx test_bit() use in the RSS, ethtool, XSK, and pool init
paths.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> index ca73a94db7943..175992188c18a 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
[ ... ]
> @@ -333,7 +333,8 @@ int otx2_set_rss_table(struct otx2_nic *pfvf, int ctx_id, const u32 *ind_tbl)
>  	/* Get memory to put this msg */
>  	for (idx = 0; idx < rss->rss_size; idx++) {
>  		/* Ignore the queue if AF_XDP zero copy is enabled */
> -		if (test_bit(ind_tbl[idx], pfvf->af_xdp_zc_qidx))
> +		if (pfvf->af_xdp_zc_qidx &&
> +		    test_bit(ind_tbl[idx], pfvf->af_xdp_zc_qidx))

[Severity: High]
This isn't a bug introduced by this patch, but since we are adding NULL
checks for test_bit() on af_xdp_zc_qidx, are we missing similar NULL checks
for set_bit() and clear_bit()?

Looking at otx2_probe() in
drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c, register_netdev()
is called before pf->af_xdp_zc_qidx is allocated:

drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c:otx2_probe() {
    ...
    err = register_netdev(netdev);
    ...
}

This creates a race window where a userspace program could immediately open
an AF_XDP socket and bind it, invoking otx2_xsk_pool_enable() which calls
set_bit() on the still-NULL pointer:

drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c:otx2_xsk_pool_enable() {
    ...
    set_bit(qidx, pf->af_xdp_zc_qidx);
    ...
}

Could this lead to a NULL pointer dereference?

[Severity: High]
This is also a pre-existing issue, but does the queue index boundary check
in otx2_sq_init() correctly identify XDP queues when attaching XSK buffers?

Looking at drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c:

drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c:otx2_sq_init() {
    ...
    if (qidx > pfvf->hw.xdp_queues)
        otx2_attach_xsk_buff(pfvf, sq, (qidx - pfvf->hw.xdp_queues));
    ...
}

If there are more normal TX queues than XDP queues (for example, 4 TX queues
and 2 XDP queues), normal TX queues (indexed 0 to 3) will evaluate to true
(e.g., 3 > 2) and erroneously receive an XSK pool.

Concurrently, the first XDP queue (index 2) would fail the evaluation
(2 > 2 is false) and its xsk_pool remains NULL.

Could this break zero-copy TX on the first XDP queue and corrupt normal
TX queues when otx2_tx_napi_handler() injects packets concurrently?

[ ... ]
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c
> index 7d67b4cbaf716..0e8a6a6486c4a 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c
[ ... ]
> @@ -193,7 +193,8 @@ int otx2_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags)
>  
>  void otx2_attach_xsk_buff(struct otx2_nic *pfvf, struct otx2_snd_queue *sq, int qidx)
>  {
> -	if (test_bit(qidx, pfvf->af_xdp_zc_qidx))
> +	if (pfvf->af_xdp_zc_qidx &&
> +	    test_bit(qidx, pfvf->af_xdp_zc_qidx))
>  		sq->xsk_pool = xsk_get_pool_from_qid(pfvf->netdev, qidx);
>  }

[Severity: High]
This is a pre-existing issue, but looking at how AF_XDP pools are enabled
in otx2_xsk_pool_enable() in this same file, it modifies the completion
queue hardware context without first disabling NAPI:

drivers/net/ethernet/marvell/octeontx2/nic/otx2_xsk.c:otx2_xsk_pool_enable() {
    ...
    otx2_clean_up_rq(pf, qidx);
    ...
}

drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c:otx2_cleanup_rx_cqes() {
    ...
    while (cq->pend_cqe) {
        cqe = (struct nix_cqe_rx_s *)otx2_get_next_cqe(cq);
    ...
}

If traffic arrives concurrently and otx2_napi_handler() in softirq context
polls the same completion queue simultaneously, can this cause a data race
and corrupt the completion queue?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821105536.2998765-1-rkannoth@marvell.com?part=1

Re: [PATCH v2 net] octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 21 Aug 2026 16:25:35 +0530 you wrote:
> From: Suman Ghosh <sumang@marvell.com>
> 
> af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is
> allocated during PF/VF probe. Representors and other non-AF_XDP paths
> leave the pointer NULL, but several call sites used test_bit() on it
> unconditionally.
> 
> [...]

Here is the summary with links:
  - [v2,net] octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup
    https://git.kernel.org/netdev/net/c/b09a0503c755

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html