CVE-2026-98906

What it actually does

Failure to restore rx->page_order, rx->max_mtu and per-port XDP RXQ page-pool registrations after lan966x_fdma_rx_alloc() fails leaves the driver running with mismatched page geometry; XDP paths then advertise frame sizes derived from the attempted MTU while actual RX pages remain from the prior allocation, enabling out-of-bounds accesses or memory corruption in the XDP fast path.

Why it matters to the business

Systems using the lan966x driver with XDP enabled can experience kernel crashes, packet drops or memory corruption during MTU changes; the two-day-old disclosure and lack of known public exploits keep immediate operational risk low, but any device relying on this driver for high-performance networking must be updated promptly to avoid future stability or security incidents.

How an attack unfolds

An attacker with the ability to trigger repeated MTU reloads (for example via privileged network configuration or adjacent network activity) forces allocation failures inside lan966x_fdma_reload(); the incomplete rollback leaves inconsistent XDP metadata, after which a subsequent XDP program or normal RX processing dereferences or writes beyond the bounds of the restored pages.

How to fix it

Upgrade to a Linux kernel containing the referenced fix that saves and restores page_order, max_mtu and the per-port XDP RXQ page-pool registrations before restarting RX; apply the vendor-supplied kernel package for the affected distribution as soon as it becomes available.

How to confirm the fix worked

After patching, confirm the lan966x driver version contains the save/restore logic for page_order, max_mtu and XDP RXQ registrations; exercise MTU changes that previously triggered allocation failures and verify that XDP frame sizes remain consistent with allocated RX pages and no warnings or crashes occur.

Typical attack path

1. Obtain privileges or network position needed to change interface MTU or trigger driver reload
2. Induce allocation failure during lan966x_fdma_rx_alloc() for the new MTU
3. Observe that rx->page_order / max_mtu and XDP RXQ registrations are not rolled back
4. Activate or continue XDP traffic that uses the advertised but incorrect frame size
5. Trigger out-of-bounds read/write or kernel panic in the XDP path

How to detect it

Search kernel logs for lan966x warnings or stack traces referencing fdma_reload, page_pool or xdp_init_buff around the time of MTU changes; inspect for unexpected XDP frame-size mismatches or page-order warnings emitted by the driver.

What your security team should do

• Prioritize kernel updates for all systems exposing the lan966x driver, especially those using XDP
• Monitor upstream stable and distribution kernel changelogs for the exact commit that restores the missing fields
• Temporarily disable XDP on lan966x interfaces if MTU reconfiguration is frequent and patching is delayed
• Include lan966x driver reload paths in regression test suites for future kernel updates