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));
> }
>
> /**
...
prev parent reply other threads:[~2026-07-31 13:50 UTC|newest]
Thread overview: 2+ 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]
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 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.