From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: Simon Horman <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, kiran.patil@intel.com,
sylwesterx.dziedziuch@intel.com, netdev@vger.kernel.org,
anthony.l.nguyen@intel.com, avinash.dayanand@intel.com
Subject: Re: [Intel-wired-lan] [PATCH iwl-net 1/5] iavf: fix null pointer dereference in iavf_detect_recover_hung
Date: Wed, 15 Apr 2026 13:48:45 +0100 [thread overview]
Message-ID: <20260415124845.797759-1-horms@kernel.org> (raw)
In-Reply-To: <20260413073035.4082204-2-aleksandr.loktionov@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
---
iavf: fix null pointer dereference in iavf_detect_recover_hung
During a concurrent reset, q_vectors are freed and re-allocated while
the watchdog task may still be iterating rings in
iavf_detect_recover_hung(). Dereferencing a NULL q_vector inside
iavf_force_wb() results in a crash. Guard against this by skipping
rings whose q_vector is NULL.
> Fixes: 9c6c12595b73 ("i40e: Detection and recovery of TX queue hung logic moved to service_task from tx_timeout")
The Fixes tag points to commit 9c6c12595b73, but that commit only modified
the i40e driver and did not introduce the iavf_detect_recover_hung function.
The bug was actually introduced by commit 07d44190a389 ("i40e/i40evf: Detect
and recover hung queue scenario"), which added iavf_detect_recover_hung with
the code pattern 'if (tx_ring && tx_ring->desc)' that calls
iavf_force_wb(vsi, tx_ring->q_vector) without checking if q_vector is NULL.
Should the Fixes tag be:
Fixes: 07d44190a389 ("i40e/i40evf: Detect and recover hung queue scenario")
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
> index 363c42bf3dcf..e7e7fc9a5c68 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
[ ... ]
> @@ -195,8 +194,11 @@ void iavf_detect_recover_hung(struct iavf_vsi *vsi)
> return;
>
> for (i = 0; i < vsi->back->num_active_queues; i++) {
> - tx_ring = &vsi->back->tx_rings[i];
> - if (tx_ring && tx_ring->desc) {
> + struct iavf_ring *tx_ring = &vsi->back->tx_rings[i];
> +
> + if (!tx_ring || !tx_ring->q_vector)
> + continue;
The check `if (!tx_ring || ...)` tests whether tx_ring is NULL, but tx_ring
is assigned as `&vsi->back->tx_rings[i]`, which is the address of an array
element. This address is always non-NULL by C language rules, as noted in
the commit message itself: "the compiler can never observe since an
array-element address is always non-NULL."
This creates misleading logic. Other similar code in the driver correctly
omits such checks (for example, in iavf_virtchnl.c and elsewhere in
iavf_txrx.c).
Should this be simplified to just check the q_vector:
if (!tx_ring->q_vector)
continue;
> + if (tx_ring->desc) {
> /* If packet counter has not changed the queue is
> * likely stalled, so force an interrupt for this
> * queue.
[ ... ]
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: aleksandr.loktionov@intel.com
Cc: Simon Horman <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, kiran.patil@intel.com,
sylwesterx.dziedziuch@intel.com, netdev@vger.kernel.org,
anthony.l.nguyen@intel.com, avinash.dayanand@intel.com
Subject: Re: [PATCH iwl-net 1/5] iavf: fix null pointer dereference in iavf_detect_recover_hung
Date: Wed, 15 Apr 2026 13:48:45 +0100 [thread overview]
Message-ID: <20260415124845.797759-1-horms@kernel.org> (raw)
In-Reply-To: <20260413073035.4082204-2-aleksandr.loktionov@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
---
iavf: fix null pointer dereference in iavf_detect_recover_hung
During a concurrent reset, q_vectors are freed and re-allocated while
the watchdog task may still be iterating rings in
iavf_detect_recover_hung(). Dereferencing a NULL q_vector inside
iavf_force_wb() results in a crash. Guard against this by skipping
rings whose q_vector is NULL.
> Fixes: 9c6c12595b73 ("i40e: Detection and recovery of TX queue hung logic moved to service_task from tx_timeout")
The Fixes tag points to commit 9c6c12595b73, but that commit only modified
the i40e driver and did not introduce the iavf_detect_recover_hung function.
The bug was actually introduced by commit 07d44190a389 ("i40e/i40evf: Detect
and recover hung queue scenario"), which added iavf_detect_recover_hung with
the code pattern 'if (tx_ring && tx_ring->desc)' that calls
iavf_force_wb(vsi, tx_ring->q_vector) without checking if q_vector is NULL.
Should the Fixes tag be:
Fixes: 07d44190a389 ("i40e/i40evf: Detect and recover hung queue scenario")
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
> index 363c42bf3dcf..e7e7fc9a5c68 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
[ ... ]
> @@ -195,8 +194,11 @@ void iavf_detect_recover_hung(struct iavf_vsi *vsi)
> return;
>
> for (i = 0; i < vsi->back->num_active_queues; i++) {
> - tx_ring = &vsi->back->tx_rings[i];
> - if (tx_ring && tx_ring->desc) {
> + struct iavf_ring *tx_ring = &vsi->back->tx_rings[i];
> +
> + if (!tx_ring || !tx_ring->q_vector)
> + continue;
The check `if (!tx_ring || ...)` tests whether tx_ring is NULL, but tx_ring
is assigned as `&vsi->back->tx_rings[i]`, which is the address of an array
element. This address is always non-NULL by C language rules, as noted in
the commit message itself: "the compiler can never observe since an
array-element address is always non-NULL."
This creates misleading logic. Other similar code in the driver correctly
omits such checks (for example, in iavf_virtchnl.c and elsewhere in
iavf_txrx.c).
Should this be simplified to just check the q_vector:
if (!tx_ring->q_vector)
continue;
> + if (tx_ring->desc) {
> /* If packet counter has not changed the queue is
> * likely stalled, so force an interrupt for this
> * queue.
[ ... ]
next prev parent reply other threads:[~2026-04-15 12:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 7:30 [Intel-wired-lan] [PATCH iwl-net 0/5] iavf: five correctness fixes Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 1/5] iavf: fix null pointer dereference in iavf_detect_recover_hung Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-15 12:48 ` Simon Horman [this message]
2026-04-15 12:48 ` Simon Horman
2026-05-11 8:25 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:25 ` Romanowski, Rafal
2026-05-11 11:39 ` Loktionov, Aleksandr
2026-05-11 11:39 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 2/5] iavf: fix error path in iavf_request_misc_irq Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-13 11:53 ` [Intel-wired-lan] " Przemek Kitszel
2026-04-13 11:53 ` Przemek Kitszel
2026-05-11 8:25 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:25 ` Romanowski, Rafal
2026-04-15 13:26 ` Simon Horman
2026-04-15 13:26 ` Simon Horman
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 3/5] iavf: prevent VSI corruption when ring params changed during reset Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-15 13:28 ` [Intel-wired-lan] " Simon Horman
2026-04-15 13:28 ` Simon Horman
2026-05-11 8:22 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:22 ` Romanowski, Rafal
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 4/5] iavf: fix TC boundary check in iavf_handle_tclass Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-15 13:46 ` [Intel-wired-lan] " Simon Horman
2026-04-15 13:46 ` Simon Horman
2026-05-11 8:22 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:22 ` Romanowski, Rafal
2026-05-11 11:32 ` Loktionov, Aleksandr
2026-05-11 11:32 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-13 7:30 ` [Intel-wired-lan] [PATCH iwl-net 5/5] iavf: return 0 when TC flower filter not found after qdisc teardown Aleksandr Loktionov
2026-04-13 7:30 ` Aleksandr Loktionov
2026-04-15 13:53 ` [Intel-wired-lan] " Simon Horman
2026-04-15 13:53 ` Simon Horman
2026-05-11 8:23 ` [Intel-wired-lan] " Romanowski, Rafal
2026-05-11 8:23 ` Romanowski, Rafal
2026-05-11 8:21 ` [Intel-wired-lan] [PATCH iwl-net 0/5] iavf: five correctness fixes Romanowski, Rafal
2026-05-11 8:21 ` Romanowski, Rafal
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=20260415124845.797759-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=avinash.dayanand@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kiran.patil@intel.com \
--cc=netdev@vger.kernel.org \
--cc=sylwesterx.dziedziuch@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.