From: Simon Horman <horms@kernel.org>
To: Jiawen Wu <jiawenwu@trustnetic.com>
Cc: netdev@vger.kernel.org,
"Mengyuan Lou" <mengyuanlou@net-swift.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Arend van Spriel" <arend.vanspriel@broadcom.com>,
"Jijie Shao" <shaojijie@huawei.com>,
"Rongguang Wei" <weirongguang@kylinos.cn>,
"Uwe Kleine-König (The Capable Hub)"
<u.kleine-koenig@baylibre.com>, "Joe Damato" <joe@dama.to>,
"Larysa Zaremba" <larysa.zaremba@intel.com>
Subject: Re: [PATCH net] net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling
Date: Fri, 31 Jul 2026 14:50:46 +0100 [thread overview]
Message-ID: <20260731135046.GI51943@horms.kernel.org> (raw)
In-Reply-To: <21947C51A754F86C+20260728093554.9324-1-jiawenwu@trustnetic.com>
On Tue, Jul 28, 2026 at 05:35:54PM +0800, Jiawen Wu wrote:
> In non-MSI-X mode (such as legacy INTx or single MSI), wx->msix_entry is
> not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences
> wx->msix_entry->entry, leading to a NULL pointer dereference crash.
>
> This issue was introduced by fixing the IRQ vector when the number of
> VFs is 7. Since macro NGBE_INTR_MISC is used in only one place and
> relies on MSI-X allocation, remove it.
>
> Fix the issue by explicitly checking WX_FLAG_IRQ_VECTOR_SHARED to
> determine the correct vector index and using BIT() to convert it into
> the interrupt mask required by wx_intr_enable().
>
> Fixes: 4174c0c331a2 ("net: ngbe: specify IRQ vector when the number of VFs is 7")
> Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
> ---
> drivers/net/ethernet/wangxun/ngbe/ngbe_main.c | 4 +++-
> drivers/net/ethernet/wangxun/ngbe/ngbe_type.h | 1 -
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c b/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
> index a16221995909..5d89fc84e8bc 100644
> --- a/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
> +++ b/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
> @@ -180,8 +180,10 @@ static void ngbe_irq_enable(struct wx *wx, bool queues)
> /* mask interrupt */
> if (queues)
> wx_intr_enable(wx, NGBE_INTR_ALL);
> + else if (test_bit(WX_FLAG_IRQ_VECTOR_SHARED, wx->flags))
> + wx_intr_enable(wx, BIT(0));
Hi Jiawen,
I am wondering if you could take a look over the following issue
which is included in the AI-generated review on sashiko.dev [1]
[1] https://sashiko.dev/#/patchset/21947C51A754F86C%2B20260728093554.9324-1-jiawenwu%40trustnetic.com
Does this change introduce a desynchronization between the software state
and the hardware configuration if SR-IOV enablement fails?
If pci_enable_sriov() fails inside wx_pci_sriov_enable(), the error path
clears the WX_FLAG_IRQ_VECTOR_SHARED flag via wx_sriov_clear_data():
wx_pci_sriov_enable() {
...
err = pci_enable_sriov(wx->pdev, num_vfs);
if (err) {
...
goto err_out;
}
...
err_out:
wx_sriov_clear_data(wx);
return err;
}
However, the hardware was already re-initialized with the MISC interrupt
mapped to vector 0. Since the hardware configuration isn't reverted, won't
subsequent shared interrupts cause the hardware to auto-mask vector 0, which
will then never be unmasked here because the flag was cleared? This appears
to result in a permanent masking of Queue 0 and MISC events.
> else
> - wx_intr_enable(wx, NGBE_INTR_MISC(wx));
> + wx_intr_enable(wx, BIT(wx->num_q_vectors));
> }
>
> /**
...
next prev parent reply other threads:[~2026-07-31 13:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 9:35 [PATCH net] net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling Jiawen Wu
2026-07-31 13:50 ` Simon Horman [this message]
2026-08-03 3:06 ` Jiawen Wu
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=20260731135046.GI51943@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=arend.vanspriel@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jiawenwu@trustnetic.com \
--cc=joe@dama.to \
--cc=kuba@kernel.org \
--cc=larysa.zaremba@intel.com \
--cc=mengyuanlou@net-swift.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shaojijie@huawei.com \
--cc=u.kleine-koenig@baylibre.com \
--cc=weirongguang@kylinos.cn \
/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