CVE-2025-21961: bnxt XDP to SKB memory accounting bug and patch

A critical memory-accounting bug in the Broadcom/NetXtreme-E (bnxt) Ethernet driver’s XDP-to-SKB conversion path can cause kernel crashes and service outages: CVE-2025-21961 is a truesize miscalculation in the bnxt XDP-MB (mb-xdp) pass case that leads to skb memory-accounting errors and kernel OOPS conditions, and vendors have released kernel updates to correct the logic.

Background / Overview​

The vulnerability stems from the interaction between three pieces of Linux networking plumbing: the XDP fast-path (specifically XDP-MB), the bnxt driver’s conversion routine that turns an XDP buffer (xdp_buff) into a kernel socket buffer (sk_buff or skb), and the kernel’s skb memory accounting (the skb->truesize field used for memory tracking and coalescing logic).
XDP (eXpress Data Path) lets eBPF programs run at the driver level to filter or redirect packets with minimal overhead. The XDP-MB mode allows drivers that manage packet data in pages (page fragments) to build skbs from xdp_buff without copying the whole packet payload. When an XDP program returns XDP_PASS in the XDP-MB path, the driver converts the xdp buffer back to an skb and calls helper functions to populate the skb's fragment and accounting information. In the bnxt driver a function named bnxt_xdp_build_skb handles that conversion and uses xdp_update_skb_shared_info to populate the skb’s shared-info and truesize. What went wrong in CVE‑2025‑21961 is an incorrect truesize value passed during that conversion. The bnxt code used a pre-stored fragment count and multiplied it by the driver’s page size constant to compute truesize, but that stored fragment count becomes stale because napi_build_skb (called earlier) has already cleared or reinitialized skb_shared_info. The stale value therefore produces an incorrect truesize that breaks skb memory accounting and can trigger kernel warnings and OOPS. Multiple distributors and security databases have documented the issue and issued kernel updates.

---

How the bug works — technical analysis​

The role of truesize and skb_shared_info​

• skb->truesize is the kernel’s accounting for the total memory backing an skb (allocation overhead + headroom + fragments). The truesize value affects memory pressure logic, coalescing, and limits that can in turn influence packet handling performance and stability.
• skb_shared_info holds metadata about non-linear fragments attached to an skb (the fragment list, number of frags, dataref counters, and other flags). Correctly populating shared_info is essential when converting from XDP page-based buffers to skbs so the networking stack knows how to treat the attached pages.

The buggy sequence in bnxt_xdp_build_skb​

• An XDP-MB program is attached and an XDP program returns XDP_PASS for a packet; the driver path converts an xdp_buff to a new sk_buff.
• bnxt_xdp_build_skb calls into xdp_update_skb_shared_info (or similar helpers) to populate fragment metadata and to compute the skb’s truesize.
• The bnxt code calculated truesize as BNXT_RX_PAGE_SIZE * sinfo->nr_frags where sinfo->nr_frags was captured earlier.
• However, napi_build_skb or other allocation code may have already zeroed or reinitialized the place where the real skb_shared_info lives — meaning the earlier-stored fragment count is no longer authoritative.
• The result is a truesize that may be wrong (too small, too large, or inconsistent), which can later cause skb_try_coalesce or other memory-coalescing and accounting code to detect inconsistencies and emit the kernel “splat” (WARNING: CPU ... skb_try_coalesce ..., followed by an oops or panic under certain workloads.

Why that leads to availability loss​

Incorrect truesize corrupts kernel expectations about skb memory layout and counts. When coalescing functions or fragment management code encounter these inconsistencies they can trigger kernel warnings and panics (OOPS). In practice, a malicious or malformed sequence of packets — for example, large fragmented frames while XDP-MB is enabled on bnxt interfaces — can repeatedly trigger the vulnerable path, resulting in repeated kernel OOPS and therefore sustained denial of service. Distributors and security trackers explicitly list availability impact and reproduce conditions that cause kernel crashes.

---

Who and what is affected​

• The bug is in the upstream Linux kernel bnxt driver (Broadcom NetXtreme-E family). Any system running an affected kernel version with the bnxt driver and with XDP-MB / XDP programs attached to bnxt-backed interfaces could be exposed.
• Several mainstream Linux distributors included the fix in their kernel advisories and have published patches for their respective kernel packages; Ubuntu, Debian, Red Hat, Oracle Linux and various enterprise kernels include advisories describing the problem and the fix. The NVD and other vulnerability trackers list this as CVE‑2025‑21961 with a medium base score (CVSSv3 ~5.5) in many vendor reports, driven by an AV:L/PR:L vector (local or privileged network access such as being able to attach XDP or send specially crafted packets to the device) and an Availability impact.

Important technical notes and caveats:

• Attack Vector and prerequisites vary by reporting vendor; many vendor writeups indicate the issue is locally reachable (i.e., requires the ability to attach XDP programs or to send large fragmented frames to a bnxt interface under specific MTU conditions). Some distros flagged higher potential impact in specific kernel/distribution contexts. Administrators must treat their environment’s configuration (XDP programs, jumbo MTU, NIC offload settings) when assessing exposure.

---

Reproduction and behavior observed​

Security posts and advisories have included reproduction guidance used by maintainers and testers. A common reproduction scenario used by testers:

• Attach an XDP program that returns XDP_PASS on the target interface.
• Configure the interface MTU to a large value (examples show MTU 9000).
• Send an oversized ping or fragmented UDP traffic, e.g., ping -s 65000 to force fragmented frames or unusual fragment counts.
• Observe kernel warnings like the skb_try_coalesce splat and eventual crash under repeated attempts.

Those reproduction steps are consistent across multiple trackers and vendor reports and explain why systems using XDP-MB with jumbo frames are a high-risk configuration. If a system does not run XDP-MB on bnxt interfaces or lacks the bnxt hardware driver, the practical risk is lower.

---

Vendor response and patches​

Major distributors and trackers (Ubuntu, Debian, Red Hat, Oracle Linux, Amazon/ALAS, OSV) have published advisories and shipped kernel updates that incorporate the upstream fix. The fix corrects the logic used to compute and pass truesize and ensures that the current, valid skb_shared_info is consulted when deciding memory accounting values rather than relying on stale stored values. Systems should be updated to vendor-supplied fixed kernel packages as soon as possible. Caveat: the upstream commit range and exact kernel commit IDs tied to the fix were published in some vulnerability databases and patch lists; however direct retrieval of the original git commit pages may require access to the kernel stable trees or browsing kernel.git pages (consult vendor advisories or kernel.org stable commit logs for the authoritative commit and back-port details). Administrators should rely on distribution advisories to get the correct package-level patches for their environment.

---

Practical mitigation and remediation steps​

The single reliable remediation is to install vendor-supplied kernel updates that include the bnxt fix. For environments that cannot patch immediately, apply these temporary mitigations in order of preference:

• 1. Patch promptly: upgrade to the fixed kernel packages provided by your distribution (Ubuntu, Red Hat/CentOS/Alma/Oracle, Amazon Linux, etc.. Kernel updates are the only permanent fix.
• 2. Detach XDP programs from bnxt interfaces: if XDP is in use on affected interfaces, remove the XDP/BPF program until the kernel has been patched:
• Example command to detach any XDP program on a device:
• ip link set dev <ifname> xdp off
• This command removes XDP processing from the interface and prevents the vulnerable bnxt XDP-MB path from being exercised. The ip link helper supports xdp off to detach programs.
• 3. Avoid jumbo frames / limit MTU: tests that reproduce the bug often use large MTU (for example 9000). If your workload permits, reducing the MTU to a standard size (1500) can reduce the chance of triggering the fragment-heavy path, but this is not a guaranteed mitigation and may affect performance. Use this only as a temporary risk reduction.
• 4. Isolate bnxt hosts: if possible, place machines with bnxt hardware under tighter network segmentation or apply ingress ACLs on upstream switches to limit large-fragment or suspicious traffic types until patches are applied.
• 5. Avoid applying experimental or untrusted XDP programs: only approved/trusted XDP code should run in production; unverified programs increase the attack surface on the XDP path.

Important operational notes:

• Detaching XDP may affect performance or other packet-processing logic; test any mitigation before applying it in production.
• Blacklisting or unloading the bnxt kernel module is a blunt instrument and may be unsafe or disruptive (it removes NIC support) — prefer the targeted XDP detachment or patching.

---

Detection and hunting​

Look for the canonical kernel OOPS symptoms reported by multiple trackers and maintainers:

• Kernel logs containing messages like:
• “WARNING: CPU: ... at net/core/skbuff.c:... skb_try_coalesce ...”
• References to skb_try_coalesce, bnxt_xdp_build_skb, or xdp_update_skb_shared_info in dmesg or /var/log/kern.log.
• Repeated OOPS or panics coinciding with high-volume or large-fragment traffic to a bnxt-backed interface.
• Presence of XDP programs attached to bnxt devices:
• ip -d link show <ifname> will indicate xdp / xdpgeneric flags when a program is active.
• Confirm driver identity:
• ethtool -i <ifname> to see driver: bnxt. Systems without bnxt driver loaded are not affected by this specific bnxt bug.

Suggested forensic commands and checks (examples):

• Check for OOPS entries:
• sudo dmesg | egrep -i 'skb_try_coalesce|bnxt_xdp_build_skb|xdp_update_skb_shared_info'
• Verify driver:
• sudo ethtool -i <ifname> | egrep 'driver|version'
• Check for XDP program:
• ip -d link show <ifname>
• If you find relevant OOPS entries, collect the kernel log, crashdump, and the exact kernel version string (uname -a) for triage and vendor support.

When estimating exposure, combine the above detection signals (bnxt driver present + XDP programs active + jumbo MTU or unusual fragment traffic) to prioritize urgent patching.

---

Exploitability and risk assessment​

• Exploitability: The vulnerability is triggered in a specific kernel path (XDP-MB PASS conversion) and typically requires either the ability to attach XDP programs to the interface or the ability to send crafted traffic that exercises the XDP-MB path under certain interface settings (jumbo frames, fragmentation). Several vulnerability trackers rate the attack vector as local or low complexity but indicate the ability to cause repeated kernel OOPS and service disruption.
• Impact: The primary impact is availability — repeated kernel crashes or persistent OOPS will cause service interruptions and potentially require manual reboots. There are no widely reported confidentiality or integrity impacts tied to arbitrary code execution from this specific bug; the driver code leads to memory-accounting inconsistencies and kernel-level faults rather than a privilege-escalation or remote code execution primitive (based on current public advisories).
• Scope: Systems using bnxt NICs with XDP-MB pathways and large-MTU configurations are the highest risk. Virtualized or cloud environments that expose bnxt-backed interfaces to untrusted tenant traffic may be at elevated risk if tenants can interact with the NIC in ways that trigger the vulnerable path.

---

Recommended timeline and actions for ops teams​

• Immediately inventory systems for bnxt driver and XDP usage:
• ethtool -i and ip -d link across server fleet.
• For hosts with bnxt + XDP in production, prioritize patching in the next maintenance window. Obtain vendor-approved kernel packages (Ubuntu, RHEL, Oracle Linux, Amazon Linux updates as applicable).
• If patching cannot be immediate, detach XDP programs from bnxt interfaces (ip link set dev <if> xdp off) and consider reducing MTU to 1500 if feasible.
• Monitor kernel logs and implement an automated alert for the skb_try_coalesce OOPS signature.
• After patching, validate by reattaching the XDP program in a controlled test and exercising high-fragment/large-payload traffic to confirm the OOPS no longer appears.

---

Strengths and weaknesses of the fix​

• Strengths:
• The upstream fix is targeted: it corrects the truesize computation and aligns the conversion helper to consult the authoritative skb_shared_info instead of stale pre-stored values.
• Distributors have rapidly packaged the fix, and standard kernel update paths are available for most enterprise Linux customers.
• Weaknesses / residual risks:
• The vulnerability sits at an uncommon but critical intersection: XDP-MB code paths are relatively new and have differing driver implementations. Similar driver-specific conversion errors could exist elsewhere; maintaining robust conversion helpers across drivers is complex.
• Systems with custom or third-party XDP programs might re-expose similar issues if programs or driver patterns rely on fragile assumptions about fragment metadata.
• Workarounds (detaching XDP, limiting MTU) may be operationally disruptive or incomplete; the only reliable mitigation remains applying vendor kernel patches.

---

Final assessment and guidance​

CVE‑2025‑21961 is a concrete example of how subtle memory-accounting mistakes in driver XDP/fragment handling can cause kernel instability and availability problems. The vulnerability is not a generic remote code-execution hole — rather, it is a local/driver-level memory-accounting bug that results in kernel oops/panic under specific conditions. Systems using bnxt NICs, XDP-MB, and large MTUs should be treated as higher priority for remediation.
Operators should:

• Treat this as an urgent kernel update for affected hosts with bnxt hardware and XDP usage.
• Prioritize deployment of distribution-provided kernel patches.
• Use short-term mitigations (detach XDP programs; limit MTU) where patching cannot be completed immediately.
• Monitor kernel logs for the signature OOPS and instrument detection to reduce time-to-detection.

Multiple distribution advisories and the NVD entry document the vulnerability, the observed kernel OOPS symptoms, and the availability impact — apply vendor-supplied patches and follow distribution guidance to remediate.

---

Appendix — quick commands and checks​

• Check for bnxt driver on an interface:
• sudo ethtool -i <ifname>
• Check if an XDP program is attached:
• ip -d link show <ifname>
• Detach XDP from an interface (temporary mitigation):
• sudo ip link set dev <ifname> xdp off
• Search kernel logs for the OOPS signature:
• sudo dmesg | egrep -i 'skb_try_coalesce|bnxt_xdp_build_skb|xdp_update_skb_shared_info'
• Confirm kernel version and vendor package updates:
• uname -a
• Use your distro package manager (apt, dnf, yum, zypper) to list available kernel updates and apply those flagged in vendor advisories.

---

Cautionary note: while multiple advisories and public trackers list reproduction steps and commit identifiers, administrators should rely on their distribution’s packaged fixes and advisories for actionable patching and version numbers. Some commit-level references circulated in vulnerability aggregators point to upstream kernel commits and ranges; consult your vendor for the exact patched package version to deploy. The bnxt truesize bug underscores the importance of rigorous review and testing in XDP/driver interactions: XDP gives powerful performance gains, but converting between driver-managed page fragments and kernel skbs demands precise memory-accounting — a single miscalculation at that boundary can render a system unavailable. Apply the vendor fixes, monitor kernel logs, and avoid reintroducing the vulnerable XDP/fragment patterns until systems are patched.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center