In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: RX, Fix XDP multi-buf frag counting for legacy RQ
XDP multi-buf programs can modify the layout of the XDP buffer when the
program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The
referenced commit in the fixes tag corrected the assumption in the mlx5
driver that the XDP buffer layout doesn't change during a program
execution. However, this fix introduced another issue: the dropped
fragments still need to be counted on the driver side to avoid page
fragment reference counting issues.
Such issue can be observed with the
test_xdp_native_adjst_tail_shrnk_data selftest when using a payload of
3600 and shrinking by 256 bytes (an upcoming selftest patch): the last
fragment gets released by the XDP code but doesn't get tracked by the
driver. This results in a negative pp_ref_count during page release and
the following splat:
WARNING: include/net/page_pool/helpers.h:297 at mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core], CPU#12: ip/3137
Modules linked in: [...]
CPU: 12 UID: 0 PID: 3137 Comm: ip Not tainted 6.19.0-rc3+ #12 NONE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core]
[...]
Call Trace:
<TASK>
mlx5e_dealloc_rx_wqe+0xcb/0x1a0 [mlx5_core]
mlx5e_free_rx_descs+0x7f/0x110 [mlx5_core]
mlx5e_close_rq+0x50/0x60 [mlx5_core]
mlx5e_close_queues+0x36/0x2c0 [mlx5_core]
mlx5e_close_channel+0x1c/0x50 [mlx5_core]
mlx5e_close_channels+0x45/0x80 [mlx5_core]
mlx5e_safe_switch_params+0x1a5/0x230 [mlx5_core]
mlx5e_change_mtu+0xf3/0x2f0 [mlx5_core]
netif_set_mtu_ext+0xf1/0x230
do_setlink.isra.0+0x219/0x1180
rtnl_newlink+0x79f/0xb60
rtnetlink_rcv_msg+0x213/0x3a0
netlink_rcv_skb+0x48/0xf0
netlink_unicast+0x24a/0x350
netlink_sendmsg+0x1ee/0x410
__sock_sendmsg+0x38/0x60
____sys_sendmsg+0x232/0x280
___sys_sendmsg+0x78/0xb0
__sys_sendmsg+0x5f/0xb0
[...]
do_syscall_64+0x57/0xc50
This patch fixes the issue by doing page frag counting on all the
original XDP buffer fragments for all relevant XDP actions (XDP_TX ,
XDP_REDIRECT and XDP_PASS). This is basically reverting to the original
counting before the commit in the fixes tag.
As frag_page is still pointing to the original tail, the nr_frags
parameter to xdp_update_skb_frags_info() needs to be calculated
in a different way to reflect the new nr_frags.
Security readout for executives and security teams
Plain-English summary
A Linux mlx5 network-driver bug can mishandle memory references when certain multi-buffer XDP programs reshape received packets. The resulting reference-count corruption may trigger kernel warnings and disrupt availability. Exposure appears limited to systems using the affected mlx5e receive path and relevant XDP behavior.
Executive priority
Treat this as a high-priority availability issue for network infrastructure matching the mlx5e/XDP conditions. Patch confirmed-exposed systems promptly, but avoid assuming fleet-wide exposure until configuration and kernel-branch validation is complete.
Technical view
On the mlx5e legacy receive queue, XDP buffer changes made through bpf_xdp_pull_data() or bpf_xdp_adjust_tail() can leave released fragments untracked. This may produce a negative page-pool reference count during page release. The kernel fix restores counting across original fragments for XDP_TX, XDP_REDIRECT, and XDP_PASS and recalculates nr_frags.
Likely exposure
Prioritize Linux hosts using mlx5e legacy receive queues with multi-buffer XDP programs, especially programs adjusting packet data or tail length. The supplied record lists affected kernel versions but does not establish which distributions, appliances, or default configurations enable the vulnerable path.
Exploitation context
The supplied CVSS is 7.5 and availability-only, with a network, low-complexity, unauthenticated vector. However, the described reproduction depends on a specific mlx5e and XDP configuration. KEV is false, and the supplied sources provide no evidence of active exploitation or a public weaponized exploit.
Researcher notes
The reported regression followed an earlier layout-handling correction. The demonstrated case uses test_xdp_native_adjst_tail_shrnk_data with a 3600-byte payload and 256-byte shrink. No confidentiality or integrity impact is asserted. The supplied version data is unusual, so branch-specific applicability should be verified against the referenced commits and vendor advisories.
Mitigation direction
Apply a vendor-supported kernel update containing the applicable referenced stable fix.
Confirm the update applies to the deployed kernel branch and distribution build.
If no update exists, request supported interim guidance from the kernel or distribution vendor.
Prioritize exposed systems running mlx5e with multi-buffer XDP on legacy receive queues.
Validation and detection
Inventory kernel versions and identify systems loading mlx5_core or using mlx5e interfaces.
Determine whether legacy receive queues and multi-buffer XDP programs are active.
Confirm the installed kernel incorporates the applicable referenced fixing commit.
Review kernel logs for page-pool warnings or negative pp_ref_count symptoms.
Use the named XDP self-test only in an approved, isolated test environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43464 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.