PT-2026-52325 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53230
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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:
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
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux