CVE-2026-53230: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-53230 Overview

CVE-2026-53230 is a slab-out-of-bounds read vulnerability in the Linux kernel's Mellanox mlx5_core network driver. The flaw resides in the mlx5_query_nic_vport_mac_list() function, which sizes its firmware command buffer using the Physical Function's (PF) log_max_current_uc/mc_list capability values. When the function queries a Virtual Function (VF) vport configured with a larger maximum list size via devlink, the firmware response overflows the undersized buffer. The condition was identified by Kernel Address Sanitizer (KASAN) during a mlx5_esw_wq workqueue execution of esw_vport_change_handler. The issue affects systems using SR-IOV with mlx5 network interfaces.

Critical Impact
An out-of-bounds read in kernel memory can lead to information disclosure, kernel instability, or crashes during VF vport address list synchronization.

Affected Products

Linux kernel versions containing the unpatched mlx5_query_nic_vport_mac_list() implementation
Systems using Mellanox ConnectX adapters with the mlx5_core driver
Deployments with SR-IOV enabled and VF MAC list maximums configured via devlink

Discovery Timeline

2026-06-25 - CVE-2026-53230 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53230

Vulnerability Analysis

The vulnerability is an out-of-bounds read [CWE-125] in the mlx5_core driver. The function mlx5_query_nic_vport_mac_list() allocates a firmware command output buffer based on the PF's log_max_current_uc_list and log_max_current_mc_list capability values. These values represent the maximum number of unicast and multicast MAC entries the PF supports.

Administrators can configure VFs with larger MAC list maximums using devlink parameters. When the driver subsequently queries a VF vport, the firmware returns a response sized to the VF's configured maximum, not the PF's. The mismatch causes the driver to read past the end of its allocated buffer when parsing the response.

The KASAN report shows the overflow triggered from the esw_vport_change_handler workqueue path through esw_update_vport_addr_list(), which is invoked during normal eswitch vport state changes.

Root Cause

The root cause is incorrect capability scoping. The function used the PF's capabilities to size a buffer that holds VF-specific data. The fix queries the vport's own Host Channel Adapter (HCA) capabilities to determine the correct buffer size. The patch also refactors the function to allocate and return the MAC list internally, removing the burden on callers to compute the correct maximum.

Attack Vector

Triggering the out-of-bounds read requires local privileges sufficient to configure VF parameters through devlink and to cause vport address list changes. The condition manifests during routine eswitch event handling on systems where a VF has been provisioned with a larger MAC list capacity than the PF. The read accesses adjacent slab memory, which may contain sensitive kernel data or cause faults depending on allocator state.

No verified public exploit code is available for this issue. Refer to the upstream patches listed in the references for the technical fix details.

Detection Methods for CVE-2026-53230

Indicators of Compromise

KASAN reports referencing mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] in kernel logs
Kernel oops or warning messages originating from esw_update_vport_addr_list or esw_vport_change_handler
Unexpected mlx5_esw_wq workqueue task crashes on hosts running SR-IOV with mlx5 adapters

Detection Strategies

Enable CONFIG_KASAN on test or staging kernels to surface out-of-bounds accesses in the mlx5_core driver path
Audit running kernel versions against the fixed commits to identify systems that still carry the vulnerable code
Review devlink configuration history for VFs with elevated max_uc_list or max_mc_list values relative to the PF

Monitoring Recommendations

Forward dmesg and /var/log/kern.log to a centralized logging system and alert on BUG: KASAN or slab-out-of-bounds strings
Monitor mlx5_core module load events and driver version strings across the fleet to track patch coverage
Track SR-IOV configuration changes that modify per-VF capability maximums

How to Mitigate CVE-2026-53230

Immediate Actions Required

Apply the upstream Linux kernel patches that fix mlx5_query_nic_vport_mac_list() buffer sizing
Inventory hosts running the mlx5_core driver with SR-IOV enabled and prioritize them for patching
Until patched, avoid configuring VFs with max_uc_list or max_mc_list values larger than the PF's reported capability

Patch Information

The fix has been merged into the Linux kernel stable trees. The patched function now sizes its buffer using the vport's own HCA capabilities and returns the allocated MAC list internally. Apply the relevant commit for your kernel branch:

Workarounds

Keep per-VF MAC list maximums equal to or smaller than the PF's log_max_current_uc_list and log_max_current_mc_list values
Restrict access to devlink administrative interfaces to trusted operators only
Defer enabling SR-IOV with custom VF resource sizing on production hosts until the kernel is updated

bash

# Check current mlx5 capability limits and devlink VF configuration
devlink dev show
devlink resource show pci/<bdf>
devlink port show

# Verify the running kernel includes the fix
uname -r
modinfo mlx5_core | grep -E 'version|srcversion'