From: Simon Horman <horms@kernel.org>
To: michael.chan@broadcom.com
Cc: Simon Horman <horms@kernel.org>,
pabeni@redhat.com, edumazet@google.com, kuba@kernel.org,
andrew.gospodarek@broadcom.com, andrew+netdev@lunn.ch,
kicinski@meta.com, netdev@vger.kernel.org,
pavan.chebbi@broadcom.com, davem@davemloft.net
Subject: Re: [net,v3,3/4] bnxt_en: Fix deleting of Ntuple filters
Date: Fri, 13 Feb 2026 16:06:04 +0000 [thread overview]
Message-ID: <20260213160604.2515258-1-horms@kernel.org> (raw)
In-Reply-To: <20260213074503.2302046-4-michael.chan@broadcom.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
---
bnxt_en: Fix deleting of Ntuple filters
This commit fixes an issue where ntuple filters deleted when the
interface is down would cause FW errors. It saves a vnic pointer in the
filter's base structure to check if the VNIC is already freed.
Fixes: 8336a974f37d ("bnxt_en: Save user configured filters in a lookup list")
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 8fc15a8353fc..1f05ecf367fe 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
[ ... ]
> @@ -6240,6 +6244,9 @@ int bnxt_hwrm_cfa_ntuple_filter_free(struct bnxt *bp,
> int rc;
>
> set_bit(BNXT_FLTR_FW_DELETED, &fltr->base.state);
> + if (fltr->base.vnic->fw_vnic_id == INVALID_HW_RING_ID)
> + return 0;
> +
Does this code dereference fltr->base.vnic without checking if it's NULL?
For ntuple drop filters created with ring_cookie == RX_CLS_FLOW_DISC, the
code sets the BNXT_ACT_DROP flag. Looking at bnxt_hwrm_cfa_ntuple_filter_alloc:
int bnxt_hwrm_cfa_ntuple_filter_alloc(struct bnxt *bp,
struct bnxt_ntuple_filter *fltr)
{
...
if (fltr->base.flags & BNXT_ACT_DROP) {
req->flags =
cpu_to_le32(CFA_NTUPLE_FILTER_ALLOC_REQ_FLAGS_DROP);
} else if (bp->fw_cap & BNXT_FW_CAP_CFA_RFS_RING_TBL_IDX_V2) {
bnxt_cfg_rfs_ring_tbl_idx(bp, req, fltr);
} else {
vnic = &bp->vnic_info[fltr->base.rxq + 1];
fltr->base.vnic = vnic;
req->dst_id = cpu_to_le16(vnic->fw_vnic_id);
}
The BNXT_ACT_DROP case sets the drop flag but doesn't initialize
fltr->base.vnic. When that filter is later freed, this code dereferences
the NULL vnic pointer.
[ ... ]
> @@ -6339,6 +6348,7 @@ int bnxt_hwrm_cfa_ntuple_filter_alloc(struct bnxt *bp,
> bnxt_cfg_rfs_ring_tbl_idx(bp, req, fltr);
> } else {
> vnic = &bp->vnic_info[fltr->base.rxq + 1];
> + fltr->base.vnic = vnic;
> req->dst_id = cpu_to_le16(vnic->fw_vnic_id);
> }
Looking at the if-else structure here:
if (fltr->base.flags & BNXT_ACT_DROP) {
req->flags =
cpu_to_le32(CFA_NTUPLE_FILTER_ALLOC_REQ_FLAGS_DROP);
} else if (bp->fw_cap & BNXT_FW_CAP_CFA_RFS_RING_TBL_IDX_V2) {
bnxt_cfg_rfs_ring_tbl_idx(bp, req, fltr);
} else {
vnic = &bp->vnic_info[fltr->base.rxq + 1];
fltr->base.vnic = vnic;
req->dst_id = cpu_to_le16(vnic->fw_vnic_id);
}
Should the BNXT_ACT_DROP case also set fltr->base.vnic?
Drop filters don't have a destination vnic, so the code doesn't set one.
But the free path in bnxt_hwrm_cfa_ntuple_filter_free now dereferences
fltr->base.vnic without a NULL check, which would crash when freeing drop
filters.
Either the drop case should explicitly set fltr->base.vnic = NULL and the
free path should check for NULL, or drop filters should be assigned a dummy
vnic. Currently the code leaves vnic uninitialized and then dereferences it.
[ ... ]
next prev parent reply other threads:[~2026-02-13 16:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 7:44 [PATCH net v3 0/4] bnxt_en: Fix RSS context and ntuple filter issues Michael Chan
2026-02-13 7:45 ` [PATCH net v3 1/4] bnxt_en: Fix RSS context delete logic Michael Chan
2026-02-13 7:45 ` [PATCH net v3 2/4] bnxt_en: Don't overload fw_vnic_id for RSS context's filters Michael Chan
2026-02-13 7:45 ` [PATCH net v3 3/4] bnxt_en: Fix deleting of Ntuple filters Michael Chan
2026-02-13 16:06 ` Simon Horman [this message]
2026-02-13 20:56 ` [net,v3,3/4] " Michael Chan
2026-02-13 7:45 ` [PATCH net v3 4/4] selftests: drv-net: rss_ctx: test RSS contexts persist after ifdown/up Michael Chan
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=20260213160604.2515258-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew.gospodarek@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kicinski@meta.com \
--cc=kuba@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.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