KernelScan.io

CRITICAL Introduced in 6.12

mlx5_vdpa DirectKeys OOB

CVE-2026-74712

CVSS 9.3 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

KernelScan AI2.3LOW

01

In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix buffer length in create_direct_keys() We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] 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. create_direct_keys 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 cmd_exec points only to the 'in' field, skipping the 'out' field. This causes mlx5_copy_to_msg() 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.

02

Engine v0.6.0

Risk summary

An out-of-bounds read of 16 bytes occurs in the mlx5 vDPA driver when creating direct MKEYs for memory regions. The input buffer length is calculated from the start of a combined structure, but the input pointer begins partway into it, causing the firmware command copy routine to read past the allocation. This is reachable only on hosts with NVIDIA/Mellanox vDPA hardware configured by an administrator, limiting exposure to virtualization deployments using vDPA acceleration.

Affecteddrivers/vdpa/mlx5/core/mr.c (mlx5 vDPA)

Vulnerability analysis

When the mlx5 vDPA driver creates direct MKEYs for a memory region, it allocates a single buffer containing an output field, an input field, and a variable-length MTT array. The length passed for the input buffer is computed as the total structure size, but the input pointer starts at the input field—after the output field—so the copy routine reads 16 bytes (the size of the output field) beyond the end of the allocation. The fix subtracts the offset of the input field from the total size so the length matches the actual data available from the pointer. This path is reached when a VMM such as QEMU sets up memory regions for a virtio device backed by an NVIDIA/Mellanox vDPA adapter, which requires the vDPA device to be configured by an administrator and the specific hardware to be present.

03

BranchIntroducedFixed inPatch commit
6.126.126.12.104ec3bb289cf19
6.186.126.18.45cde8931a2539
7.16.127.1.96c8a9f7bc003
mainline6.127.2727e1f569855
cip/6.126.126.12.104-cip30ec3bb289cf19

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.104-cip30