CVE-2026-74712: vdpa/mlx5: Fix buffer length in create_direct_keys()
In the Linux kernel, the following vulnerability has been resolved:
vdpa/mlx5: Fix buffer length in createdirectkeys()
We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmdexec+0x550/0xca0 [mlx5core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmdexec+0x550/0xca0 [mlx5core] [<000011388ab3b61c>] mlx5cmdexeccb+0x25c/0x4f0 [mlx5core] [<000011388b21e82e>] mlx5vdpaexecasynccmds+0x22e/0x5e0 [mlx5vdpa] [<000011388b21fd44>] createdirectkeys+0x954/0xef0 [mlx5vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation. createdirectkeys calculates the pointer and length for in and out buffers. The size calculation for in includes the entire structure size (out + in + mtt[]) but the pointer passed to cmdexec points only to the 'in' field, skipping the 'out' field.
This causes mlx5copytomsg() to read beyond the allocated buffer by sizeof(out) bytes when copying command data.
Properly calculate the input size to match the pointer and allocation size.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's mlx5 vDPA driver are implicated, specifically when create_direct_keys() is exercised. The reported failing task was qemu-system-s39, but the data does not establish that all QEMU configurations are affected.
What is required to trigger the out-of-bounds read?
The vulnerable path requires execution of create_direct_keys() in mlx5_vdpa, which submits command buffers through mlx5_core. The provided data does not identify a remote attack vector, required privileges, or a specific guest-controlled trigger.
How can I determine whether a system is exhibiting the problem?
Kernel AddressSanitizer may report a slab-out-of-bounds read in mlx5_core cmd_exec, reached through mlx5_cmd_exec_cb, mlx5_vdpa_exec_async_cmds, and create_direct_keys. The described failure reads 16 bytes beyond a 4384-byte allocation.
What should be changed to remediate the issue?
Apply a kernel update containing the fix referenced in the supplied stable kernel commits. The correction makes the create_direct_keys() input buffer length match the pointer to the in field rather than including the preceding out field.