A serious bug was discovered in the Broadcom NetXtreme (bnxt_en) Ethernet driver for the Linux kernel. This bug, tracked as CVE-2021-47015, could cause kernel crashes and system instability on servers and desktops using modern Broadcom network cards. Let’s break down what happened, how it was fixed, and why this matters.
Where Was the Bug?
The bnxt_en driver handles incoming network packets by tracking their progress with an “RX consumer index.” If this index — a counter — gets out of order, it's supposed to mean a serious hardware error happened, so the driver needs to wind everything down gracefully.
But in the function bnxt_rx_pkt() (the packet receive code), if an error happens and packets aren't processed in the correct order, the function would use the wrong index to signal which packet to abort. This can easily send the driver into a crash situation.
The driver expected packets in order.
- When they arrived out of order (a hardware problem), it would try to “clean up” by discarding the remaining packets.
- But it passed the *old* index (raw_cons) instead of the *current* index (tmp_raw_cons) to its cleanup code.
- This mismatch eventually led to the driver accessing the wrong memory — causing a kernel page fault (crash).
When triggered, you might see a crash log like this in your dmesg or console
# [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007
#1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232
#2 [ffff9bbcdf5c3ad] panic at ffffffff9b07d61e
...
[exception RIP: bnxt_rx_pkt+237]
RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213
RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e ...
This shows the kernel has panicked while running inside bnxt_rx_pkt().
Here’s a simplified version
...
if (raw_cons != expected_cons) {
// Error, hardware bug -- discard the rest
bnxt_discard_rx(bp, rxr, raw_cons); // raw_cons is wrong here!
} else {
// Handle packet normally
}
...
In the fixed version, the developers replaced raw_cons with the right variable
...
if (raw_cons != expected_cons) {
// Error, hardware bug -- discard the rest
bnxt_discard_rx(bp, rxr, tmp_raw_cons); // NOW correct!
} else {
// Handle packet normally
}
...
Impact
- Crash Risk: With the bug present, receiving out-of-order packets due to hardware glitches could instantly crash the system.
- Server Stability: Any server using modern Broadcom adapters with heavy network load risked downtime.
Data Loss: A kernel panic usually means lost network connections and possibly data corruption.
- Attack Potential: Although exploitation might be tricky (since it relies on hardware misbehavior), a skilled attacker with local system access *could* try to manually inject bad packets or simulate hardware faults.
Exploit Details
Is it exploitable from the outside?
In practice, exploiting this kind of race reliably is hard. You'd have to trick the hardware or the driver into completing RX ring buffers out-of-order. That usually requires low-level hardware access, but in some virtualized or compromised environments, it could be doable.
Here is a hypothetical proof-of-concept in *pseudo-code* for an advanced attacker or penetration tester:
// Pseudocode for exploit attempt:
open_broadcom_device();
inject_packets_to_rx_ring_with_forced_out_of_order_completion();
// Monitor for kernel OOPS or panic as described above.
More realistically, this bug increases the risk from flaky hardware or a compromised, malicious driver.
Mitigations & Patch
The mainline Linux kernel fixed this problem in Commit 4bf2efb4847b:
> "bnxt_en: Fix RX consumer index logic in the error path."
>
> Passed the correct consumer index to the discard function to prevent out-of-bounds memory access and kernel crash.
Upgrade recommended:
If you use Broadcom NetXtreme or NetXtremeII adapters, update your kernel to at least the version including this patch, or ask your vendor for a backport!
References and Further Reading
- CVE-2021-47015 at NVD
- Linux Kernel Commit: RX consumer index fix
- LKML Patch Discussion
- bnxt_en Driver Documentation
Conclusion
The bnxt_en RX consumer index bug is a classic case of a “one wrong variable, big crash” bug. While hard to exploit deliberately, it exposes important Linux systems to unpredictable kernel panics due to rare network hardware misbehavior. Always keep your kernel up to date — sometimes, it’s one line of code between uptime and disaster.
*Written by AI forensic security analyst, exclusively for you.*
Timeline
Published on: 02/28/2024 09:15:38 UTC
Last modified on: 01/08/2025 18:12:23 UTC