CVE-2024-53209

What it actually does

MTU change after XDP multi-buffer attachment leaves aggregation ring configuration and rx_skb_func handler out of sync with bnxt_set_rx_skb_mode(), allowing hardware DMA of packets larger than allocated receive buffers and resulting in memory corruption or NULL pointer dereference crashes in bnxt_rx_pkt.

Why it matters to the business

Unexpected kernel crashes and potential data corruption on systems using bnxt_en NICs with XDP, causing service outages, reduced availability for high-performance networking workloads, and increased operational overhead for recovery and investigation.

How an attack unfolds

An attacker with local or network-adjacent access triggers the race by attaching an XDP multi-buffer program at one MTU, then forcing an MTU change through configuration or packet-induced path, after which incoming traffic causes the driver to miscalculate buffer sizes and the hardware writes beyond allocated memory, leading to crashes or memory corruption that can be chained for denial of service or limited code execution in kernel context.

How to fix it

Upgrade the Linux kernel to the commit c9c3395d5e3dcc6daee66c6908354d47bf98cb0c or later that calls bnxt_set_rx_skb_mode() inside bnxt_change_mtu() and clears BNXT_FLAG_NO_AGG_RINGS at the start of bnxt_set_rx_skb_mode(); rebuild and reboot with the patched kernel; test MTU changes under XDP workloads before production deployment.

How to confirm the fix worked

Verify the running kernel contains commit c9c3395d5e3dcc6daee66c6908354d47bf98cb0c, reproduce MTU change scenarios with XDP multi-buffer attached, and confirm absence of out-of-sync aggregation ring settings or crashes in bnxt_rx_pkt; inspect dmesg for the resolved synchronization logic.

Typical attack path

1. Attach XDP multi-buffer program while MTU is set
2. Change MTU via interface configuration or external trigger
3. Send or receive traffic that exercises the receive path
4. Hardware performs DMA exceeding the now-mismatched buffer size
5. Kernel hits NULL dereference or corruption in bnxt_rx_pkt leading to panic or exploitable state

How to detect it

Search kernel logs and crash dumps for bnxt_rx_pkt stack traces, NULL pointer dereferences at addresses such as 00000000000003c0, and messages referencing bnxt_en with XDP or MTU changes; correlate with interface configuration change events and XDP program loads.

• bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en]
• BUG: kernel NULL pointer dereference, address: 00000000000003c0
• bnxt_set_rx_skb_mode
• BNXT_FLAG_NO_AGG_RINGS
• Hardware name: Wiwynn Delta Lake

What your security team should do

• Apply the referenced kernel commit immediately on all systems using bnxt_en with XDP
• Prioritize patching production hosts handling high network throughput first
• Add monitoring for bnxt_en related kernel oops and panics
• Test MTU reconfiguration procedures under load in staging environments
• Review XDP attachment workflows to ensure MTU is stable before attachment