Look up another CVE · open CVE-2023-53394 in the interactive tracker
CVE-2023-53394
net/mlx5e: xsk: Fix crash on regular rq reactivation
Published 2025-09-18 (13 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2023-53394 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.4.11-1 | Update the kernel and reboot. Fixed in 6.4.11-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.4.11-1 | Update the kernel and reboot. Fixed in 6.4.11-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.4.11-1 | Update the kernel and reboot. Fixed in 6.4.11-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When the regular rq is reactivated after the XSK socket is closed it could be reading stale cqes which eventually corrupts the rq. This leads to no more traffic being received on the regular rq and a crash on the next close or deactivation of the rq. Kal Cuttler Conely reported this issue as a crash on the release path when the xdpsock sample program is stopped (killed) and restarted in sequence while traffic is running. This patch flushes all cqes when during the rq flush. The cqe flushing is done in the reset state of the rq. mlx5e_rq_to_ready code is moved into the flush function to allow for this.
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_main.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
- 2025-09-18 (13 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 2.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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.1 | 6.4.10 | 02a84eb2af6b |
| 6.1 | 6.5 | 39646d9bcd1a |
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:LAttack vector, local
- The bug is triggered by local AF_XDP bind/teardown that calls ndo_bpf(XDP_SETUP_XSK_POOL) into mlx5e_xsk_enable/disable_locked, which flushes and later reactivates the regular RQ; remote packets alone cannot drive that control path.
- AC:LAttack complexity, low
- The attacker fully controls XSK open/close (and can generate the concurrent RX traffic that leaves stale CQEs), so the flush-without-CQE-drain then reactivate sequence is reliably inducible with no race or layout outside attacker influence.
- PR:LPrivileges required, low
- AF_XDP creation only needs ns_capable(CAP_NET_RAW), and XDP/XSK setup needs CAP_NET_ADMIN/CAP_BPF in the netns owner user_ns; both are obtainable via unshare -Urn, including on an mlx5 VF delegated into a container netns.
- UI:NUser interaction, none
- The attacker loads XDP, binds/closes the XSK socket, and supplies traffic entirely on its own; no separate victim action is required.
- S:UScope, unchanged
- Impact is confined to the host kernel’s mlx5e RQ/page-pool objects within the same OS security authority, with no VM escape, IOMMU bypass, or sandbox boundary crossed.
- C:HConfidentiality impact, high
- Processing stale CQEs against a refilled RQ desynchronizes WQE/page accounting so completion and free_rx_descs can release or reuse page_pool pages still referenced elsewhere, yielding a use-after-free read primitive over reclaimed pages.
- I:HIntegrity impact, high
- The same RQ corruption produces page double-free/UAF on the close/deactivate path (and DMA into recycled buffers while HW may still complete), which with heap spraying is exploitable for arbitrary kernel memory corruption and control-flow hijack.
- A:HAvailability impact, high
- The commit-documented result is RQ corruption that stops RX and crashes on the next close/deactivation (oops/panic), which is a full availability loss.