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 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.
Security readout for executives and security teams
Plain-English summary
A Linux mlx5 vDPA driver flaw can make the kernel read 16 bytes beyond an allocated buffer while creating direct keys. The supplied record rates potential impact as critical, but the evidence describes a CI-detected memory-safety failure—not a demonstrated attack or confirmed real-world exploitation.
Executive priority
Treat as urgent for virtualization or networking hosts using mlx5 vDPA, given the critical 9.3 score and kernel memory-safety impact. Prioritize exposure confirmation and vendor-supported updates. Broader emergency action is not justified solely by the bundle because exploitation has not been reported.
Technical view
In create_direct_keys(), the command input pointer starts at the in field, while its calculated length incorrectly includes the preceding out field. mlx5_copy_to_msg() can therefore read sizeof(out), reported as 16 bytes, beyond a 4,384-byte allocation. KASAN observed the fault through mlx5 command execution during QEMU activity.
Likely exposure
Exposure appears limited to affected Linux versions using the mlx5 vDPA path. Systems without the relevant mlx5 vDPA functionality are less likely to reach the flawed code. The supplied affected-version data is ambiguous, so confirm exact kernel status against distribution or vendor advisories.
Exploitation context
The CVSS vector specifies local access, low complexity, no privileges, and no user interaction. However, the bundle provides no exploit demonstration, weaponization evidence, or confirmed attack path. The CVE is not listed in KEV, so active exploitation should not be assumed.
Researcher notes
The concrete evidence is an out-of-bounds read reproduced under KASAN in CI. Although CVSS claims high confidentiality, integrity, and availability impact with changed scope, the supplied narrative does not establish how the 16-byte over-read produces those outcomes. Exact vulnerable release boundaries also require vendor confirmation.
Mitigation direction
Apply a vendor kernel update incorporating the referenced stable fix.
Prioritize hosts actively using mlx5 vDPA or affected virtualization workloads.
Consult distribution guidance to map packaged kernels to the upstream fixes.
Restrict untrusted local workload access where immediate updating is unavailable.
Validation and detection
Inventory kernel versions and determine whether mlx5 vDPA is enabled or used.
Compare vendor kernel changelogs against CVE-2026-74712 and referenced commits.
Review KASAN, kernel, and mlx5 logs for slab-out-of-bounds reports.
Confirm updated kernels contain the corrected create_direct_keys() input-size calculation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-74712 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
5Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.