---

Summary:
A critical bug was discovered (and fixed) in the Linux kernel's bnxt Ethernet driver that could lead to kernel NULL pointer dereference and system crash when toggling XDP (eXpress Data Path) configurations. This post breaks down the root cause of CVE-2025-21682, how the bug manifests, its exploitability, and why this "minor annoyance" escalated into a crash scenario. All details here are written in clear American language, with practical examples and original references at the end.

What is Affected?

- Component: Linux kernel bnxt (Broadcom NetXtreme-C/E Ethernet) driver

Versions: All versions with XDP support in bnxt before the fix

- Patched in: This kernel commit
- Attack vector: Local; interaction with XDP + ring/channel configuration

The Problem

When XDP is _detached_ from an interface using the bnxt driver, the driver fails to recalculate the interface features (like HW-GRO). This might seem unimportant at first. But if you change other network settings (like the number of RX rings or channels) after XDP is turned off, the driver state can become inconsistent.

This results in a kernel crash—specifically, a NULL pointer dereference.

Before the Fix

# Attach XDP program
ip link set dev eth xdp obj xdp_dummy.bpf.o sec xdp
# Remove XDP program
ip link set dev eth xdp off
# Check hardware GRO state
ethtool -k eth | grep gro
# Output: rx-gro-hw: off [requested on]

In this state, HW-GRO (hardware-based Generic Receive Offload) stays disabled even though you expect it to come back. Worse, the "pending" re-enablement can trigger a crash if you reconfigure rings/channels now.

After the Fix

ip link set dev eth xdp obj xdp_dummy.bpf.o sec xdp
ip link set dev eth xdp off
ethtool -k eth | grep gro
# Output: rx-gro-hw: on

Now the hardware GRO feature is properly re-enabled.

The Big Issue (Exploitable Scenario)

If you change the number of RX rings just after toggling XDP off, the driver may try to reconfigure the hardware state using out-of-date or invalid pointers. Since a key piece of driver logic only updates RSS (Receive Side Scaling) tables if it thinks the effective number of RX rings has changed, sometimes it skips updates—leaving stale pointers around.

When a later network change (_e.g._ through ethtool -L eth combined X) happens, the driver accesses a freed ring and crashes:

BUG: kernel NULL pointer dereference, address: 0000000000000168
RIP: 001:__bnxt_hwrm_vnic_set_rss+x13a/x1a
  ...
  ethtool_set_channels+x18c/x1d

This null pointer dereference can be triggered by any local user with network admin capabilities. That means a guest on a cloud VM or container can trivially kill their host's kernel if bnxt hardware is in use.

Here's the relevant pseudo-code from the driver (simplified)

if (old_rx_rings != bp->hw_resc.resv_rx_rings) {
    // Only update RSS table if ring count changed
    update_rss_map();
} else {
    // No update
}
// ... But pointer state may be stale here, leading to crash

The fix is to always recalculate features (and thus ensure ring mappings are valid) after XDP is turned off, regardless of ring count arithmetic.

Warning: running this on a vulnerable system will crash the kernel!

# 1. Attach XDP program (puts driver into special mode)
ip link set dev eth xdp obj xdp_dummy.bpf.o sec xdp

# 2. Detach XDP program (without forcing feature recalculation)
ip link set dev eth xdp off

# 3. Change ring/channel configuration
ethtool -L eth combined $((NEW_VALUE))
# At this point, kernel may dereference a NULL pointer and crash.

- Exact trigger details depend on timing, but toggling XDP and quickly reducing ring count is a reliable method.

Success is indicated by a hard kernel crash and a stack trace similar to the one in the logs above.

## How to Fix / Mitigate

- Kernel update: Users and vendors must upgrade to a kernel that includes this patch _(mainline commit id: a646e7e0133d)_, or backport the change.
- Workaround: Avoid toggling XDP and changing RX ring count without a reboot in between (infeasible for many environments).

References

- CVE-2025-21682 (NVD entry)
- Linux kernel commit fixing the issue
- LKML Patch Discussion
- Upstream bug tracker (if available)

Conclusion

Though it might seem like an "annoyance" that hardware receive offload features don’t come back right away after XDP is turned off, the deeper issue is a kernel crash waiting to happen due to invalid state and pointer usage in the bnxt driver. This is a high-value target in enterprise and cloud networks.

Admins should patch immediately. For researchers, this is a textbook example of why always recalculating state after low-level hardware config changes matters in kernel and driver development.


Share this post to help administrators and kernel maintainers keep their Linux systems stable and secure!

Timeline

Published on: 01/31/2025 12:15:29 UTC
Last modified on: 02/04/2025 15:25:48 UTC