CVE-2026-43465

What it actually does

This is a Linux kernel memory-management flaw in the Mellanox/NVIDIA mlx5 Ethernet driver receive path when XDP multi-buffer programs are used with striding receive queues. Certain XDP operations, such as bpf_xdp_pull_data() or bpf_xdp_adjust_tail(), can change the fragment layout of an XDP buffer. The driver incorrectly fails to account for fragments that were present in the original buffer but later dropped or rearranged by the XDP program. That mismatch can corrupt page-pool fragment reference counts, producing negative reference-count conditions and potentially causing kernel warnings, memory corruption, packet-processing instability, or system crashes. The issue affects XDP_TX, XDP_REDIRECT, and XDP_PASS paths.

Why it matters to the business

Systems using affected Linux kernels with mlx5-based high-speed network adapters and XDP multi-buffer packet-processing programs may experience kernel instability, degraded network service, or crashes under specific packet-processing conditions. For organizations using Linux hosts for edge networking, load balancing, DDoS filtering, packet capture, service mesh acceleration, or high-throughput container networking, exploitation or accidental triggering could interrupt critical network traffic. Although the CVSS score is critical, this vulnerability has not been reported as exploited in CISA KEV, is not known to be used in ransomware campaigns, has no known public exploit maturity in the provided data, and has a low EPSS score; prioritization should be highest for exposed systems that actually use mlx5 hardware with XDP multi-buffer programs.

How an attack unfolds

An attacker targets a Linux system that uses an affected kernel, an mlx5 network interface, striding receive queues, and an XDP multi-buffer program. The attacker sends network traffic that causes the XDP program to manipulate the packet buffer layout, for example by pulling packet data into the linear area or adjusting the packet tail so that an original fragment is dropped. The mlx5 driver then processes the modified XDP buffer but does not correctly count all original fragments before releasing page-pool memory. Repeated triggering can create page-fragment reference-count inconsistencies. When the receive queue is later recycled, closed, or reconfigured, the corrupted accounting can surface as kernel warnings, memory corruption, or a crash. There are no named threat actors or active exploitation reports in the provided intelligence, so this should be treated as a high-impact kernel stability issue with exposure dependent on mlx5/XDP deployment details.

How to fix it

Update to a Linux kernel build that includes the upstream mlx5e fix for XDP multi-buffer fragment counting in striding receive queues. Where distribution-specific fixed package versions are not available, use the latest vendor-supported kernel for the affected distribution or appliance and confirm that the fix for net/mlx5e RX XDP multi-buffer fragment counting has been backported. If immediate patching is not possible, reduce exposure by disabling or removing XDP multi-buffer programs on mlx5 interfaces, disabling XDP on affected interfaces where operationally feasible, avoiding configurations that use mlx5 striding receive queues with XDP multi-buffer processing, or moving high-risk packet-processing workloads to unaffected hardware or patched hosts. Treat mitigations as temporary because the underlying kernel memory-management bug remains present until the driver fix is applied.

How to confirm the fix worked

Confirm the running kernel package or kernel commit level includes the mlx5e fix for counting all original XDP buffer fragments across XDP_TX, XDP_REDIRECT, and XDP_PASS paths. Validate vendor advisories or changelogs for the affected distribution, appliance, or kernel tree. On representative patched systems, verify that mlx5 interfaces with XDP multi-buffer programs can process traffic and undergo MTU changes, interface resets, or queue reconfiguration without producing page-pool reference-count warnings. If safe in a lab, reproduce the relevant XDP multi-buffer selftest scenario, particularly drivers/net/xdp.py test_xdp_native_tx_mb, and confirm it passes without mlx5e_page_release_fragmented warnings. Operationally, inventory hosts for mlx5_core/mlx5e usage and XDP program attachment using tools such as bpftool, ip link, ethtool, and kernel package inventory.

Typical attack path

1. Identify or reach a Linux host using an affected kernel with mlx5-based network hardware.
2. Rely on the target having XDP multi-buffer programs enabled on the mlx5 interface.
3. Send packets that cause the XDP program to call operations such as bpf_xdp_pull_data() or bpf_xdp_adjust_tail(), changing the original fragment layout.
4. Trigger XDP actions such as XDP_PASS, XDP_TX, or XDP_REDIRECT after the fragment layout has changed.
5. Cause the mlx5 driver to miscount original page-pool fragments during receive-buffer processing.
6. Repeat or wait for queue teardown, MTU change, interface reset, or receive-queue cleanup to release the affected fragments.
7. Observe or induce kernel warnings, memory corruption symptoms, network disruption, or host crash.

How to detect it

Look for evidence of kernel warnings, crashes, or instability in systems using mlx5 network drivers with XDP enabled. Primary log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, and monitoring alerts for interface resets or host reboots. Search for kernel splats referencing mlx5e_page_release_fragmented, mlx5e_free_rx_mpwqe, mlx5e_dealloc_rx_mpwqe, page_pool helpers, negative reference counting, or XDP multi-buffer tests. Correlate events with XDP program attachment changes, unusually malformed or minimal network packets, MTU changes, interface down/up events, ethtool configuration changes, driver reloads, or receive-queue reconfiguration. Also review bpftool output and change records for XDP programs that call bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The most likely observable artifacts are denial-of-service symptoms and kernel diagnostics rather than durable attacker-created files or processes.

• WARNING: CPU:
• mlx5e_page_release_fragmented
• include/net/page_pool/helpers.h
• mlx5e_free_rx_mpwqe
• mlx5e_dealloc_rx_mpwqe
• mlx5e_free_rx_descs
• mlx5e_close_rq
• mlx5e_close_queues
• mlx5e_close_channel
• mlx5e_safe_switch_params
• mlx5e_change_mtu
• mlx5e_change_nic_mtu
• net/mlx5e
• mlx5_core
• test_xdp_native_tx_mb
• drivers/net/xdp.py
• bpf_xdp_pull_data
• bpf_xdp_adjust_tail
• XDP_PASS
• XDP_TX
• XDP_REDIRECT
• page_pool
• negative reference counting

What your security team should do

• Prioritize patching Linux systems that combine affected kernels, mlx5-based network adapters, and XDP multi-buffer programs, especially internet-facing or high-throughput network infrastructure.
• Inventory mlx5 driver usage by identifying loaded mlx5_core/mlx5e modules and Mellanox/NVIDIA ConnectX-class adapters across Linux fleets.
• Inventory XDP usage on mlx5 interfaces with bpftool and ip link, and flag interfaces with native XDP or multi-buffer-capable programs attached.
• Monitor kernel logs for mlx5e page-pool reference-count warnings, kernel splats, receive-queue teardown crashes, and unexplained network-interface resets.
• If patching is delayed, temporarily disable XDP programs on affected mlx5 interfaces or move XDP packet-processing workloads to patched systems.
• Schedule maintenance testing for MTU changes, interface resets, and driver reloads on patched systems to ensure the issue no longer reproduces.
• Track distribution and appliance vendor advisories because fixed versions may vary by downstream kernel package and backport policy.
• Because this is not currently KEV-listed and has low EPSS, use exposure-based prioritization rather than broad emergency action for systems that do not use mlx5 XDP multi-buffer processing.