CVE-2026-53230

What it actually does

This is a Linux kernel memory-corruption flaw in the Mellanox/NVIDIA mlx5 network driver. The vulnerable code sizes a firmware command response buffer using physical-function capabilities, then queries a virtual-function vport that may have a larger configured unicast or multicast MAC list limit. That mismatch can cause the driver to read or process data beyond the allocated slab buffer in kernel context when handling vport address-list updates. Practical impact is most likely kernel memory corruption, warning/panic, or denial of service on systems using mlx5 hardware with SR-IOV/devlink configuration; reliable arbitrary code execution is not indicated by the available information.

Why it matters to the business

Organizations running Linux hosts with mlx5-based network adapters, especially virtualization, cloud, NFV, or high-performance networking platforms using SR-IOV virtual functions, could experience host instability or outages if the flaw is triggered. Because this is not in CISA KEV, has low EPSS, and has no known public exploit maturity, immediate internet-wide exploitation is unlikely; however, kernel-driver crashes on infrastructure hosts can still disrupt many workloads at once.

How an attack unfolds

An attacker would need a path to influence mlx5 VF vport configuration or trigger vport MAC-list updates on a vulnerable host. In a typical scenario, a user with sufficient local, administrative, container-host, or tenant-adjacent control over SR-IOV VF networking causes a VF vport to have a larger configured MAC-list maximum than the PF-derived value used by the vulnerable driver allocation path. When the mlx5 eswitch workqueue processes a vport change, the driver calls mlx5_query_nic_vport_mac_list(), receives or parses a firmware response sized for the VF’s actual capabilities, and accesses beyond the slab allocation. The resulting condition may be observed as a KASAN slab-out-of-bounds report, kernel oops, driver failure, or host crash. There is no current indication that this vulnerability is remotely exploitable over normal network traffic without access to relevant host/VF management surfaces.

How to fix it

Upgrade to a Linux kernel version or vendor backport that includes the mlx5 fix for sizing mlx5_query_nic_vport_mac_list() buffers using the queried vport’s own HCA capabilities. If exact fixed package versions are not available, follow the kernel, distribution, hypervisor, appliance, or NIC-vendor advisory for this CVE and apply the first security update containing the mlx5_core patch. Reboot into the fixed kernel after installation. If immediate patching is not possible, reduce exposure by limiting access to host networking administration, devlink, SR-IOV VF provisioning, and VF MAC-list configuration; disable SR-IOV/VF features on affected mlx5 devices where operationally feasible; and restrict untrusted tenants or workloads from controlling mlx5 VF configuration.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix, not just that an updated package is installed. Check the active kernel version with uname and compare it to the distribution or vendor advisory containing the mlx5 patch. Verify mlx5_core is loaded only on patched kernels where mlx5 hardware is present. Where source or debuginfo is available, confirm the patched implementation queries the vport’s own HCA capabilities and allocates the MAC list internally rather than relying on PF-derived log_max_current_uc/log_max_current_mc sizing. Review boot and kernel logs after reboot for absence of mlx5_query_nic_vport_mac_list, KASAN slab-out-of-bounds, esw_vport_change_handler, or mlx5_core oops messages during VF configuration tests.

Typical attack path

1. Identify a Linux system using the mlx5_core driver with Mellanox/NVIDIA mlx5 hardware and SR-IOV or embedded switch functionality enabled.
2. Obtain sufficient privileges or management access to alter VF/vport MAC-list-related configuration, such as through host networking controls, devlink, virtualization orchestration, or privileged local access.
3. Configure or trigger a VF vport state where its effective unicast or multicast MAC-list capacity exceeds the PF-derived value used by the vulnerable allocation path.
4. Cause a vport address-list update or eswitch event so the mlx5 eswitch workqueue queries the VF vport MAC list.
5. Trigger the out-of-bounds kernel memory access in mlx5_query_nic_vport_mac_list().
6. Use the resulting kernel warning, oops, panic, or driver instability to cause denial of service or potentially explore further memory-corruption effects.

How to detect it

Look for evidence of kernel memory-corruption reports, driver crashes, or host panics involving mlx5_core and the vulnerable call path. Primary log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, hypervisor host logs, crash dump metadata, kdump/vmcore records, and infrastructure automation logs that record SR-IOV, devlink, VF, or MAC-list changes. Search for KASAN slab-out-of-bounds reports referencing mlx5_query_nic_vport_mac_list, esw_update_vport_addr_list, esw_vport_change_handler, or the mlx5_esw_wq workqueue. Correlate any such crash with recent devlink or network configuration changes to VF/vport MAC-list limits, SR-IOV enablement, VF provisioning, or tenant workload activity. Because public attacker tooling and strong network IOCs are not available, detection should focus on host telemetry, kernel crash artifacts, and suspicious privileged changes to mlx5 VF configuration rather than packet signatures.

• BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list
• mlx5_query_nic_vport_mac_list+
• esw_update_vport_addr_list+
• esw_vport_change_handle_locked+
• esw_vport_change_handler+
• Workqueue: mlx5_esw_wq esw_vport_change_handler
• mlx5_core
• Read of size 4 at addr
• KASAN: slab-out-of-bounds
• devlink
• log_max_current_uc
• log_max_current_mc

What your security team should do

• Inventory Linux hosts that load mlx5_core, especially virtualization, Kubernetes, cloud, NFV, storage, and high-performance networking nodes using SR-IOV or mlx5 eswitch features.
• Prioritize patching hosts where untrusted or semi-trusted users, tenants, containers, or automation can influence VF/vport configuration.
• Apply the fixed kernel or vendor backport and reboot into the patched kernel; verify the running kernel is the fixed version.
• Until patched, restrict devlink, iproute2, hypervisor, and orchestration permissions that can modify mlx5 VF or vport MAC-list settings.
• Monitor kernel logs for mlx5_core slab-out-of-bounds, KASAN, oops, panic, or eswitch workqueue errors that may indicate attempted triggering or instability.
• If suspicious crashes are observed, preserve kernel logs, vmcore/kdump artifacts, and recent network-device configuration changes for forensic review.
• Treat repeated mlx5_core crashes on multi-tenant or shared infrastructure as a potential abuse signal even though known exploitation is currently not reported.