In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix slab-out-of-bounds in mlx5querynicvportmac_list
mlx5querynicvportmaclist() sizes its firmware command buffer using the PF's logmaxcurrentuc/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 mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] 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: mlx5eswwq eswvportchangehandler [mlx5core] Call Trace: <TASK> dumpstacklvl+0x69/0xa0 printreport+0x176/0x4e4 kasanreport+0xc8/0x100 mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] eswupdatevportaddrlist+0x2e3/0xda0 [mlx5core] eswvportchangehandlelocked+0xa1f/0x1060 [mlx5core] eswvportchangehandler+0x6a/0x90 [mlx5core] processonework+0x87f/0x15e0 workerthread+0x62b/0x1020 kthread+0x375/0x490 retfromfork+0x4dc/0x810 retfromforkasm+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.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53230.json",
"cna_assigner": "Linux"
}