CVE-2025-21682: eth: bnxt: always recalculate features after XDP clearing, fix null-deref
In the Linux kernel, the following vulnerability has been resolved:
eth: bnxt: always recalculate features after XDP clearing, fix null-deref
Recalculate features when XDP is detached.
Before:
# ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
# ip li set dev eth0 xdp off
# ethtool -k eth0 | grep gro
rx-gro-hw: off [requested on]
After:
# ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
# ip li set dev eth0 xdp off
# ethtool -k eth0 | grep gro
rx-gro-hw: on
The fact that HW-GRO doesn't get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn't handle reconfiguring
two things at a time very robustly.
Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") we only reconfigure the RSS hash table
if the "effective" number of Rx rings has changed. If HW-GRO is
enabled "effective" number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement "pending"
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:
if (old_rx_rings != bp->hw_resc.resv_rx_rings &&
condition in __bnxt_reserve_rings() will be false.
The RSS map won't get updated, and we'll crash with:
BUG: kernel NULL pointer dereference, address: 0000000000000168
RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0
bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180
__bnxt_setup_vnic_p5+0x58/0x110
bnxt_init_nic+0xb72/0xf50
__bnxt_open_nic+0x40d/0xab0
bnxt_open_nic+0x2b/0x60
ethtool_set_channels+0x18c/0x1d0
As we try to access a freed ring.
The issue is present since XDP support was added, really, but
prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") it wasn't causing major issues.
Security readout for executives and security teams
Plain-English summary
A Linux network-driver state bug can crash a system when XDP is removed and network channels are later reconfigured. Exploitation requires local privileges and a specific bnxt interface state, limiting broad exposure. Successful triggering may disrupt availability and potentially affect data confidentiality or integrity according to the supplied CVSS assessment.
Executive priority
Prioritize internet-facing, critical, or high-availability Linux systems using bnxt interfaces, especially where delegated administrators or automation reconfigure networking. Treat as a focused high-severity reliability and privilege-bound security issue, not evidence of a broadly remote compromise path.
Technical view
Detaching XDP fails to recalculate bnxt features, leaving hardware GRO restoration pending. A later channel reconfiguration can incorrectly skip rebuilding the RSS map, causing access to a freed ring and a kernel NULL-pointer dereference. The supplied CVSS 3.1 score is 7.3 with local, low-privilege, no-interaction requirements.
Likely exposure
Exposure is concentrated on Linux systems using the bnxt Ethernet driver where users can manage XDP and network-channel configuration. The supplied affected-version data lists 4.16, 6.1.167, 6.6.130, 6.12.11, and 6.13, but distribution and vendor backports require separate confirmation.
Exploitation context
The supplied record does not report active exploitation and states KEV is false. Triggering requires local access with sufficient privileges to alter interface XDP and channel settings, followed by a particular reconfiguration sequence. No evidence establishes remote exploitation.
Researcher notes
The failure depends on stale feature state after XDP detachment: hardware GRO remains logically pending, ring-count calculations can cancel during channel reduction, and RSS-map rebuilding is skipped. The record attributes major impact to behavior introduced by commit 98ba1d931f61, while noting the underlying issue dates to initial XDP support.
Mitigation direction
Update to a vendor-supported kernel containing the applicable stable-kernel fix.
Confirm distribution or appliance remediation status because kernel backports may change version-based conclusions.
Restrict privileges permitting XDP attachment, detachment, and network-channel reconfiguration.
Avoid affected bnxt reconfiguration workflows until remediation when operationally feasible.
Validation and detection
Inventory Linux systems using the bnxt driver and record their exact vendor kernel builds.
Determine whether local users or services can modify XDP and interface channel settings.
Verify the installed kernel includes the relevant stable fix or vendor backport.
Review kernel logs for bnxt RSS failures, NULL-pointer dereferences, or crashes during interface reconfiguration.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-476: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-476 · source CWE mapping
NULL Pointer Dereference
NULL Pointer Dereference represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.