CVE-2024-53209 - Linux Kernel bnxt_en Memory Corruption via MTU Change When XDP is Active
A serious vulnerability has been found and patched in the Linux kernel’s bnxt_en ethernet driver, tracked as CVE-2024-53209. The bug allowed for random memory corruption and kernel crashes due to bad receive ring configurations when using XDP and changing the network MTU. This could potentially allow attackers to crash impacted systems or, in some extreme cases, escalate privileges.
In this post, we’ll break down the issue in simple terms, show you the key code, give links to references and provide details a researcher or sysadmin should know.
What is bnxt_en and Why Does MTU Matter?
The bnxt_en driver powers Broadcom NetXtreme Ethernet adapters (common in enterprise servers). The MTU (Maximum Transmission Unit) defines how big a network packet can be.
If you’re using XDP (eXpress Data Path) for high-speed packet processing, the way Linux structures incoming packet “rings” (memory buffers) depends on the MTU at the time XDP is enabled. If you later change the MTU without telling XDP, memory mismatches happen.
The Vulnerability: Out-Of-Sync Ring Parameters
When you attach an XDP program, the kernel chooses buffer settings based on the current MTU. It uses two key things:
Which function handles received sockets (rx_skb_func)
Previously, if you then changed the MTU, the aggregation decision could get out of sync. Your hardware might DMA (Direct Memory Access) data larger than the allocated buffer, leading to memory corruption.
The result? Kernel null pointer OOPS, random crashes, or worse.
Real Crash Example
BUG: kernel NULL pointer dereference, address: 00000000000003c
...
RIP: 001:bnxt_rx_pkt+xe97/x1ae [bnxt_en]
...
Call Trace:
<IRQ>
__bnxt_poll_work+x1c2/x3e [bnxt_en]
Exploitability
Is this RCE (remote code execution)?
Not directly—there’s no straightforward way to remotely run code. But, attackers _on the same machine with network privileges_ could trigger system instability or possibly gain further control in conjunction with other bugs.
Vulnerable Code: Where Things Went Wrong
In the function that reacts to MTU changes, the driver didn’t sync its aggregation ring settings or function pointers.
The old code (concept)
int bnxt_change_mtu(struct net_device *dev, int new_mtu)
{
// ... do some configuration
// Forgets to update RX ring settings!
return ;
}
They now _always call_ bnxt_set_rx_skb_mode() in bnxt_change_mtu().
- This re-evaluates whether aggregation rings are needed based on the _new_ MTU and updates rx_skb_func safely.
The patch in simple C
int bnxt_change_mtu(struct net_device *dev, int new_mtu)
{
struct bnxt *bp = netdev_priv(dev);
// Ensure RX ring settings match new MTU
bnxt_set_rx_skb_mode(bp);
// ... the rest of the configuration
return ;
}
void bnxt_set_rx_skb_mode(struct bnxt *bp)
{
// Always start as if no AGG rings
bp->flags &= ~BNXT_FLAG_NO_AGG_RINGS;
// Set or clear, based on MTU and XDP
if (XDP_ENABLED && MTU_LARGE) {
bp->flags |= BNXT_FLAG_NO_AGG_RINGS;
// Use aggregation
} else {
// Use standard rings
}
// Set correct rx_skb_func handler
}
How to Detect and Fix
Systems affected:
MTU changed after enabling XDP
Symptoms:
OOPS in bnxt_rx_pkt
What to do:
Upgrade your kernel to a version with the fix (June 2024 or later)
- Ubuntu Patch Reference
- Kernel.org Patch Link
Pass large packets (ex: with iperf or ping -s)—the kernel may crash!
ethtool --set-priv-flags eth xdpdrv on
ip link set dev eth mtu 900
ping -s 8972 $SOME_HOST
# Watch for kernel OOPS
References
- CVE-2024-53209 at Mitre
- Linux Kernel Patch Commit
- Ubuntu Security Notice USN-694-1
- XDP Project
- Original kernel bug report (mailing list)
Conclusion
CVE-2024-53209 is a classic example of a subtle but dangerous driver bug—simply changing configuration at the wrong time could cause kernel memory corruption, especially in high-performance environments. Keep your kernels updated, and never underestimate the importance of internal driver sanity checks when using advanced Linux networking features like XDP.
If you use Broadcom adapters and XDP, patch immediately—this one’s easy to trigger, and the window for an attacker isn’t theoretical.
*Post written exclusively for this request; feel free to use and share with colleagues and fellow sysadmins!*
Timeline
Published on: 12/27/2024 14:15:28 UTC
Last modified on: 03/06/2025 12:42:52 UTC