CVE-2026-43464

What it actually does

This flaw affects the Linux kernel Mellanox/NVIDIA mlx5 Ethernet driver when XDP multi-buffer processing is used with legacy receive queues. Certain XDP programs can change packet buffer layout, for example by shrinking or pulling packet data, and the driver may fail to account for all original fragments when releasing page-pool-backed receive buffers. The result is incorrect page fragment reference counting, including negative page-pool reference counts, which can trigger kernel warnings and potentially destabilize networking or the host. The practical security impact is denial of service through kernel/network-driver instability rather than data disclosure or privilege escalation.

Why it matters to the business

Systems using affected Linux kernels with mlx5-based network adapters and XDP multi-buffer workloads may experience network disruption, interface resets, kernel warnings, or host instability. For organizations using high-throughput Linux networking, load balancers, packet filters, container networking, DDoS mitigation, or eBPF/XDP-based telemetry on mlx5 hardware, exploitation or accidental triggering could interrupt production traffic. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so urgency is highest for exposed high-availability systems using mlx5 drivers with XDP enabled.

How an attack unfolds

An attacker would need to cause traffic to be processed by an affected mlx5 receive path where XDP multi-buffer programs are active. The triggering condition involves packet buffers with multiple fragments and XDP logic that changes the buffer layout, such as calls equivalent to bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). When the driver later handles actions such as XDP_PASS, XDP_TX, or XDP_REDIRECT, fragment accounting can become inconsistent with the original buffer layout. When receive queues are closed, reconfigured, or descriptors are freed, the driver may release fragments with incorrect reference counts, producing page-pool warnings and potentially disrupting the interface or host. In many environments this may be more likely to be triggered by local configuration, XDP program behavior, or crafted network traffic reaching an already deployed XDP program than by a fully unauthenticated remote attacker alone.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream mlx5e fix for XDP multi-buffer fragment accounting in legacy receive queues. Because no exact fixed versions were provided, use distribution security advisories from Red Hat, Ubuntu, Debian, SUSE, Oracle, Amazon Linux, NVIDIA/Mellanox, and other kernel suppliers to identify the patched kernel for each platform. If immediate patching is not possible, reduce exposure by disabling or removing XDP programs on mlx5 interfaces where feasible, avoiding XDP multi-buffer features on affected systems, disabling legacy receive queue configurations if an alternative receive mode is available and supported, or moving critical traffic away from affected hosts. Schedule reboots where required, because kernel and driver updates typically require rebooting or module reloads to take effect safely.

How to confirm the fix worked

Confirm the running kernel contains the vendor fix, not only that an updated package is installed. Validate with uname -r, package manager metadata, vendor advisory references, and, where possible, kernel changelog entries mentioning mlx5e XDP multi-buffer fragment counting or page_pool reference-count fixes. On mlx5 systems, confirm loaded driver versions with ethtool -i <interface> and lsmod/modinfo mlx5_core. Review whether XDP programs are attached using ip link show, bpftool net, and bpftool prog. After remediation, run controlled regression tests for XDP multi-buffer traffic, MTU changes, interface reset, and XDP_PASS/XDP_TX/XDP_REDIRECT behavior while monitoring dmesg and journald for mlx5e or page_pool warnings. Absence of the known warning after equivalent traffic and queue reconfiguration is a useful operational validation, but patch-level verification remains the primary proof of remediation.

Typical attack path

1. Identify or reach a Linux system using the mlx5_core/mlx5e driver with XDP multi-buffer processing enabled.
2. Send traffic patterns that produce multi-fragment receive buffers, such as larger packets or packets handled across multiple fragments.
3. Rely on an installed XDP program that modifies buffer layout, for example by shrinking tail data or pulling packet data.
4. Trigger XDP actions such as XDP_PASS, XDP_TX, or XDP_REDIRECT on the modified multi-buffer packet.
5. Cause or wait for receive queue cleanup, MTU change, queue reconfiguration, interface reset, or descriptor freeing.
6. The driver performs incorrect page fragment accounting, leading to page-pool reference-count warnings and possible network or system instability.

How to detect it

Look for evidence of prior triggering in kernel and system logs rather than application logs. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, netconsole, crash dumps, kdump/vmcore analysis, and monitoring alerts for NIC resets or host instability. Search for kernel warnings involving mlx5_core, mlx5e_page_release_fragmented, mlx5e_dealloc_rx_wqe, mlx5e_close_rq, page_pool helpers, negative pp_ref_count, and stack traces occurring around MTU changes, interface resets, XDP program changes, or high-volume large-packet traffic. Also review shell history, audit logs, and network configuration management for ip link set mtu, XDP attach/detach operations, bpftool activity, or automated network reconfiguration near the warning time. For forensic triage, correlate warning timestamps with drops in interface availability, driver reloads, queue resets, pod/node network failures, or unexpected packet-processing changes. There are no known unique remote exploit payload indicators in the supplied data; detection should focus on kernel artifacts and operational symptoms.

• mlx5e_page_release_fragmented
• WARNING: include/net/page_pool/helpers.h
• negative pp_ref_count
• mlx5e_dealloc_rx_wqe
• mlx5e_free_rx_descs
• mlx5e_close_rq
• mlx5e_close_queues
• mlx5e_close_channel
• mlx5e_close_channels
• mlx5e_safe_switch_params
• mlx5e_change_mtu
• xdp_update_skb_frags_info
• mlx5_core
• bpf_xdp_adjust_tail
• bpf_xdp_pull_data
• XDP_TX
• XDP_REDIRECT
• XDP_PASS
• ip link set dev
• ip link set mtu
• bpftool prog
• bpftool net

What your security team should do

• Inventory Linux systems using mlx5_core/mlx5e drivers, especially high-throughput network appliances, Kubernetes nodes, load balancers, packet-processing hosts, and systems running eBPF/XDP programs.
• Prioritize patching systems where mlx5 hardware and XDP are both present, particularly Internet-facing or high-availability network paths.
• Check for attached XDP programs with bpftool and ip link; temporarily disable nonessential XDP programs on affected hosts until patched.
• Monitor kernel logs for mlx5e_page_release_fragmented, page_pool reference-count warnings, receive queue cleanup failures, interface resets, and unexpected MTU or link reconfiguration events.
• Coordinate kernel upgrades with operations teams because remediation may require rebooting production network nodes.
• If patching is delayed, consider traffic failover or maintenance windows for systems carrying critical workloads to reduce the business impact of driver instability.
• Treat exploitation likelihood as currently low based on the supplied EPSS and KEV status, but do not ignore the issue on systems where XDP and mlx5 are central to network availability.