In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix XDP_TX path
For XDP_TX action in bnxt_rx_xdp(), clearing of the event flags is not
correct. __bnxt_poll_work() -> bnxt_rx_pkt() -> bnxt_rx_xdp() may be
looping within NAPI and some event flags may be set in earlier
iterations. In particular, if BNXT_TX_EVENT is set earlier indicating
some XDP_TX packets are ready and pending, it will be cleared if it is
XDP_TX action again. Normally, we will set BNXT_TX_EVENT again when we
successfully call __bnxt_xmit_xdp(). But if the TX ring has no more
room, the flag will not be set. This will cause the TX producer to be
ahead but the driver will not hit the TX doorbell.
For multi-buf XDP_TX, there is no need to clear the event flags and set
BNXT_AGG_EVENT. The BNXT_AGG_EVENT flag should have been set earlier in
bnxt_rx_pkt().
The visible symptom of this is that the RX ring associated with the
TX XDP ring will eventually become empty and all packets will be dropped.
Because this condition will cause the driver to not refill the RX ring
seeing that the TX ring has forever pending XDP_TX packets.
The fix is to only clear BNXT_RX_EVENT when we have successfully
called __bnxt_xmit_xdp().
Security readout for executives and security teams
Plain-English summary
A flaw in the Linux bnxt_en network driver can eventually stop an affected receive ring from accepting traffic when XDP_TX is used. Packets are then dropped, creating a denial-of-service condition for traffic handled by that interface. The supplied CVSS score is 7.5 because availability can be severely affected without compromising confidentiality or integrity.
Executive priority
Prioritize prompt remediation where affected Broadcom interfaces and XDP_TX support production, security, or high-availability traffic. An outage could isolate services even though data theft or modification is not indicated. Systems without bnxt_en or XDP_TX are less likely to be exposed and should be verified through inventory rather than assumed vulnerable.
Technical view
During repeated NAPI polling, bnxt_rx_xdp() can incorrectly clear BNXT_TX_EVENT. If the XDP transmit ring is full, the event is not restored, so pending packets do not trigger the TX doorbell. The receive ring then stops refilling and eventually drops all packets. The fix clears only BNXT_RX_EVENT after __bnxt_xmit_xdp() succeeds.
Likely exposure
Exposure requires Linux systems using the Broadcom bnxt_en driver with XDP_TX processing. The bundle lists affected versions including 6.8, 6.12.64, 6.18.3, and 6.19, but its version data includes an ambiguous โ0โ entry and does not provide clear range boundaries. Confirm status against vendor kernels and fix backports.
Exploitation context
The CVSS vector describes network-reachable, low-complexity, unauthenticated impact requiring no user interaction. However, the supplied sources do not document active exploitation, public exploit code, or confirmed malicious use, and the CVE is not listed as KEV in the bundle. Treat this primarily as an availability risk in configurations that exercise XDP_TX.
Researcher notes
The failure is an event-flag state-management bug rather than documented memory corruption. Earlier BNXT_TX_EVENT state can be lost during another XDP_TX iteration when transmission cannot proceed, leaving the producer ahead without a doorbell. Multi-buffer processing should retain existing event flags. Exact affected-version boundaries and downstream backport status require vendor confirmation.
Mitigation direction
Update to a vendor-supported kernel containing the applicable bnxt_en stable fix.
Check distribution advisories for backports because kernel version numbers alone may be misleading.
Prioritize systems using bnxt_en with XDP_TX on availability-critical network paths.
If immediate updating is impossible, consult vendor guidance for configuration-specific mitigations.
Validation and detection
Inventory hosts loading bnxt_en and identify interfaces configured for XDP_TX.
Verify kernel packages include one of the cited fixes or an equivalent vendor backport.
Review interface telemetry for sustained receive drops, stalled traffic, or ring depletion symptoms.
After remediation, confirm normal packet handling and receive-ring refill under authorized operational testing.
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.
cve ยท low confidence lookup
CVE-2025-68770 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
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.