From: Jakub Kicinski <kuba@kernel.org>
To: anthony.l.nguyen@intel.com
Cc: Jakub Kicinski <kuba@kernel.org>,
andrew+netdev@lunn.ch, avigailx.dahan@intel.com,
boolli@google.com, aaron.ma@canonical.com, decot@google.com,
willemb@google.com, przemyslaw.kitszel@intel.com,
sridhar.samudrala@intel.com, aleksandr.loktionov@intel.com,
davem@davemloft.net, pabeni@redhat.com, sreedevi.joshi@intel.com,
Samuel.salin@intel.com, netdev@vger.kernel.org,
sx.rinitha@intel.com, joshua.a.hay@intel.com, tglx@kernel.org,
dima.ruinskiy@intel.com, emil.s.tantilov@intel.com,
david.m.ertman@intel.com, stable@vger.kernel.org,
brianvv@google.com, pmenzel@molgen.mpg.de, edumazet@google.com,
horms@kernel.org, piotr.kwapulinski@intel.com, joe@dama.to,
rafal.romanowski@intel.com, brett.creeley@amd.com,
mschmidt@redhat.com, jacob.e.keller@intel.com,
intel-wired-lan@lists.osuosl.org, vitaly.lifshits@intel.com,
jedrzej.jagielski@intel.com
Subject: Re: [net,v2,02/12] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL
Date: Thu, 26 Feb 2026 19:56:25 -0800 [thread overview]
Message-ID: <20260227035625.2632753-1-kuba@kernel.org> (raw)
In-Reply-To: <20260225211546.1949260-3-anthony.l.nguyen@intel.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL
This patch adds a NULL check for rx_qgrp->splitq.bufq_sets to prevent
kernel panic when idpf_rxq_group_alloc() fails during initialization and
the error path calls idpf_rxq_sw_queue_rel(). The panic was occurring
during device opening when adding to a bonding interface.
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> index 761a77510467..59aafadae3d0 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> @@ -1341,6 +1341,9 @@ static void idpf_txq_group_rel(struct idpf_q_vec_rsrc *rsrc)
> */
> static void idpf_rxq_sw_queue_rel(struct idpf_rxq_group *rx_qgrp)
> {
> + if (!rx_qgrp->splitq.bufq_sets)
> + return;
> +
> for (unsigned int i = 0; i < rx_qgrp->splitq.num_bufq_sets; i++) {
> struct idpf_bufq_set *bufq_set = &rx_qgrp->splitq.bufq_sets[i];
>
> for (unsigned int j = 0; j < bufq_set->num_refillqs; j++) {
> kfree(bufq_set->refillqs[j].ring);
> bufq_set->refillqs[j].ring = NULL;
^^^^^^
This patch adds a NULL check for bufq_sets, but does the same issue
exist for refillqs?
Looking at idpf_rxq_group_alloc() in the same file, it first sets
bufq_set->num_refillqs to a non-zero value, then attempts to allocate
refillqs:
idpf_rxq_group_alloc() {
...
bufq_set->num_refillqs = num_rxq;
bufq_set->refillqs = kcalloc(bufq_set->num_refillqs,
sizeof(struct idpf_sw_queue),
GFP_KERNEL);
if (!bufq_set->refillqs) {
err = -ENOMEM;
goto err_alloc;
}
...
}
If this allocation fails, bufq_set->refillqs is NULL but
bufq_set->num_refillqs is non-zero. The error path calls
idpf_rxq_sw_queue_rel() which now passes the bufq_sets check but then
dereferences bufq_set->refillqs[j].ring in the inner loop.
The inner loop condition (j < bufq_set->num_refillqs) would be true,
causing the same NULL pointer dereference the patch is meant to prevent.
Would this need a similar check before the inner loop, similar to the
bufq_sets check added in this patch?
next prev parent reply other threads:[~2026-02-27 3:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 21:15 [PATCH net v2 00/12][pull request] Intel Wired LAN Driver Updates 2026-02-19 (idpf, ice, i40e, ixgbevf, e1000e) Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 01/12] idpf: increment completion queue next_to_clean in sw marker wait routine Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 02/12] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL Tony Nguyen
2026-02-27 3:56 ` Jakub Kicinski [this message]
2026-03-02 22:02 ` [net,v2,02/12] " Hay, Joshua A
2026-02-25 21:15 ` [PATCH net v2 03/12] idpf: skip deallocating txq group's txqs " Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 04/12] idpf: nullify pointers after they are freed Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 05/12] idpf: change IRQ naming to match netdev and ethtool queue numbering Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 06/12] idpf: Fix flow rule delete failure due to invalid validation Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 07/12] ice: recap the VSI and QoS info after rebuild Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 08/12] ice: fix crash in ethtool offline loopback test Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 09/12] i40e: Fix preempt count leak in napi poll tracepoint Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 10/12] ixgbevf: fix link setup issue Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 11/12] e1000e: introduce new board type for Panther Lake PCH Tony Nguyen
2026-02-25 21:15 ` [PATCH net v2 12/12] e1000e: clear DPG_EN after reset to avoid autonomous power-gating Tony Nguyen
2026-02-28 16:50 ` [PATCH net v2 00/12][pull request] Intel Wired LAN Driver Updates 2026-02-19 (idpf, ice, i40e, ixgbevf, e1000e) patchwork-bot+netdevbpf
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=20260227035625.2632753-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=Samuel.salin@intel.com \
--cc=aaron.ma@canonical.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=avigailx.dahan@intel.com \
--cc=boolli@google.com \
--cc=brett.creeley@amd.com \
--cc=brianvv@google.com \
--cc=davem@davemloft.net \
--cc=david.m.ertman@intel.com \
--cc=decot@google.com \
--cc=dima.ruinskiy@intel.com \
--cc=edumazet@google.com \
--cc=emil.s.tantilov@intel.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=jedrzej.jagielski@intel.com \
--cc=joe@dama.to \
--cc=joshua.a.hay@intel.com \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=piotr.kwapulinski@intel.com \
--cc=pmenzel@molgen.mpg.de \
--cc=przemyslaw.kitszel@intel.com \
--cc=rafal.romanowski@intel.com \
--cc=sreedevi.joshi@intel.com \
--cc=sridhar.samudrala@intel.com \
--cc=stable@vger.kernel.org \
--cc=sx.rinitha@intel.com \
--cc=tglx@kernel.org \
--cc=vitaly.lifshits@intel.com \
--cc=willemb@google.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