Look up another CVE · open CVE-2026-43464 in the interactive tracker
CVE-2026-43464
net/mlx5e: RX, Fix XDP multi-buf frag counting for legacy RQ
Published 2026-05-08 (5 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-43464 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 6.19.10-1 | Update the kernel and reboot. Fixed in 6.19.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.19.10-1 | Update the kernel and reboot. Fixed in 6.19.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
- What this is
- MELLANOX ETHERNET DRIVER (mlx5e)MAINTAINERS section matched on drivers/net/ethernet/mellanox/mlx5/core/en_* · netdev@vger.kernel.org · Maintained
- Kernel module
- mlx5_core
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_MLX5_CORE|CONFIG_MLX5_CORE_EN|CONFIG_NET_VENDOR_MELLANOX' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w mlx5_corePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormm
- trixieMnot built on armel/rpi
- forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_MLX5_CORE, CONFIG_MLX5_CORE_EN, CONFIG_NET_VENDOR_MELLANOX
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-05-08 (5 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.73%, higher than 53.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18 | 6.18.19 | c74557495efb |
| 6.18 | 6.19.9 | 03cb50e5b74f |
| 6.18 | 7.0 | a6413e6f6c9d |
| 6.6.115 | 0 | 0 |
| 6.12.56 | 0 | 0 |
| 6.17.6 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The vulnerable mlx5e RX path is reached by packets received on a Mellanox Ethernet interface, before any network-layer authentication. A remote peer can supply the packet sizes and traffic needed to enter the multi-buffer receive path.
- AC:LAttack complexity, low
- Once an affected deployment has an XDP multi-buffer program using layout-changing helpers, triggering only requires sending packets that span fragments and cause the program to shrink or pull data. The packet pattern is attacker-controlled and no race or hard-to-hit timing condition is required.
- PR:NPrivileges required, none
- The attacker does not need local privileges or credentials to send packets to the affected interface. Attaching the XDP program is a deployment precondition, but the vulnerable receive path itself is unauthenticated packet processing.
- UI:NUser interaction, none
- No victim user action is needed after the affected interface and XDP program are in service. Packet reception alone drives the vulnerable code.
- S:UScope, unchanged
- The bug corrupts accounting inside the same kernel/network-device security authority. It does not cross a VM, IOMMU, or other separate security boundary.
- C:NConfidentiality impact, none
- The investigated bug is a page-pool fragment reference accounting undercount that leads to negative reference counts and warnings, not an exposed arbitrary read or bounded information leak. The fixed code corrects lifetime accounting rather than a data disclosure path.
- I:NIntegrity impact, none
- The issue does not provide a demonstrated primitive for attacker-controlled data modification or control-flow hijack. The corruption is limited to page-pool reference accounting for receive buffers.
- A:HAvailability impact, high
- The malformed accounting triggers WARN_ON splats in page_pool release and can be driven repeatedly through received traffic followed by normal queue teardown or reconfiguration. In severe reasonable deployments, including systems with panic_on_warn or exhausted RX page-pool resources, this can cause a kernel-level denial of service.