public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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?

  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