Look up another CVE · open CVE-2026-53230 in the interactive tracker
CVE-2026-53230
net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list
Published 2026-06-25 (4 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-2026-53230 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.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 </TASK> Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.
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/eswitch.c
drivers/net/ethernet/mellanox/mlx5/core/vport.c
include/linux/mlx5/vport.h
- What this is
- MELLANOX MLX5 core VPI driverMAINTAINERS section matched on drivers/net/ethernet/mellanox/mlx5/core/ · netdev@vger.kernel.org · Maintained
- Kernel module
- mlx5_core
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_MLX5_CORE|CONFIG_MLX5_ESWITCH|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.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_MLX5_CORE, CONFIG_MLX5_ESWITCH, 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-06-25 (4 months ago)source
- CVSS
- 8.7 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 2.0% 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 |
|---|---|---|
| 4.5 | 6.6.143 | 41781f278930 |
| 4.5 | 6.12.94 | 537d87784e81 |
| 4.5 | 6.18.36 | 0f807764bb12 |
| 4.5 | 7.0.13 | 2398e497389e |
| 4.5 | 7.1 | 894e036a24a2 |
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 vulnerable PF eswitch worker is reached through local VF/device control paths, not by ordinary remote packets. A plausible severe scenario is a tenant or container with local control of an mlx5 SR-IOV VF triggering vport MAC-list changes.
- AC:LAttack complexity, low
- There is no race or timing requirement; once a VF vport has a larger MAC-list capability than the PF-sized query buffer, changing the VF MAC filter state deterministically queues the PF query path. The required SR-IOV/devlink configuration is an affected deployment condition.
- PR:LPrivileges required, low
- The host/VF must be in an affected mlx5 SR-IOV configuration, but the triggering MAC-list changes can be made from delegated VF/net namespace privileges such as CAP_NET_RAW or CAP_NET_ADMIN rather than host root. User namespaces and containerized VF deployments make this closer to low privilege than real host-admin-only access.
- UI:NUser interaction, none
- No victim user action is needed after the affected VF is available. The attacker can trigger the vport context change directly through local network-device control operations.
- S:CScope, changed
- In SR-IOV or passthrough deployments, a VF-side actor can cause faults in the host PF eswitch driver. That crosses the VF/guest security boundary into the host kernel’s security authority.
- C:HConfidentiality impact, high
- The bug reads past the allocated firmware command response buffer while copying MAC entries, exposing adjacent kernel heap contents in principle. The out-of-bounds read is not strictly limited to only a few bytes.
- I:LIntegrity impact, low
- The read data is consumed as MAC-list state and can result in unintended eswitch/FDB address programming, but the investigated path does not show an arbitrary kernel write primitive. This supports limited integrity impact rather than full code execution.
- A:HAvailability impact, high
- The reported failure is a KASAN slab-out-of-bounds in a kernel workqueue, and on affected systems it can oops or panic the host kernel. The trigger can be repeated through VF MAC-list changes.