CVE-2026-74712: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-74712 Overview

CVE-2026-74712 is an out-of-bounds read vulnerability in the Linux kernel's vdpa/mlx5 driver. The flaw resides in the create_direct_keys() function within the mlx5_vdpa module. The function miscalculates the input buffer length passed to cmd_exec(), causing mlx5_copy_to_msg() to read sizeof(out) bytes beyond the allocated buffer. A Kernel Address Sanitizer (KASAN) trace captured in continuous integration testing recorded a 272-byte read at an address 4128 bytes into a 4384-byte allocation, confirming a 16-byte overrun. The condition is triggered during virtio data path acceleration (vDPA) key creation on Mellanox ConnectX network adapters.

Critical Impact
Local attackers with the ability to exercise the mlx5 vDPA command interface can trigger kernel memory disclosure or destabilize the host, with potential impact on confidentiality, integrity, and availability of virtualized workloads.

Affected Products

Linux kernel builds shipping the mlx5_vdpa driver prior to the fix commits
Systems using Mellanox ConnectX adapters with vDPA acceleration enabled
Hypervisor hosts running QEMU/KVM workloads backed by mlx5 vDPA devices

Discovery Timeline

2026-08-22 - CVE-2026-74712 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74712

Vulnerability Analysis

The vulnerability is an out-of-bounds read [CWE-125] in the create_direct_keys() function of the mlx5_vdpa kernel module. The function constructs a firmware command that carries an out header, an in header, and a variable-length mtt[] translation table. It allocates a single buffer large enough to hold all three sections. When issuing the command through mlx5_cmd_exec_cb(), the code passes a pointer offset to the in field but supplies a length that still includes the size of the out field. mlx5_copy_to_msg() therefore walks sizeof(out) bytes past the end of the allocation while copying command data into the firmware mailbox.

The KASAN report captured in the upstream commit shows a read of 272 bytes at offset 4128 within a 4384-byte slab object, confirming a 16-byte overrun consistent with the size difference between the out header and the requested read length. The overread can expose adjacent slab contents to the firmware command path and, depending on the neighboring allocation, can also lead to a kernel oops.

Root Cause

The root cause is a size and pointer mismatch. The pointer argument advances past the out header, but the length argument continues to describe the full structure size, sizeof(out) + sizeof(in) + mtt_size. The fix, applied in commits 6c8a9f7bc003, 727e1f569855, cde8931a2539, and ec3bb289cf19, recalculates the input length to match the offset pointer.

Attack Vector

Exploitation requires local access on a host that exposes an mlx5 vDPA device to a workload capable of triggering direct key creation, such as a QEMU guest using vhost-vdpa. The KASAN trace shows the faulting path originating from qemu-system-s39, indicating that a guest-driven control-plane operation reaches the vulnerable code. No user interaction is required, and the scope changes because the read occurs in kernel context on behalf of a lower-privileged workload. No public proof-of-concept exploit is currently listed, and the issue is not on the CISA Known Exploited Vulnerabilities catalog.

The vulnerability manifests entirely inside kernel command marshaling. See the upstream commits referenced below for the exact diff to create_direct_keys().

Detection Methods for CVE-2026-74712

Indicators of Compromise

KASAN slab-out-of-bounds reports naming cmd_exec+0x550/0xca0 [mlx5_core] in dmesg or the kernel journal
Kernel oops or mlx5_core firmware command failures correlated with vDPA guest startup
Unexpected mlx5_vdpa_exec_async_cmds errors in host logs during virtual machine provisioning

Detection Strategies

Enable KASAN in test kernels to catch the overread deterministically before production rollout
Inventory hosts running the mlx5_vdpa module with lsmod | grep mlx5_vdpa and correlate against patched kernel versions
Track kernel package versions across the fleet and flag any host still exposing vDPA acceleration on an unpatched build

Monitoring Recommendations

Forward /var/log/kern.log and journald kernel entries to a centralized data lake and alert on KASAN, mlx5_core, and mlx5_vdpa error signatures
Monitor guest lifecycle operations that create vDPA devices and correlate with host kernel warnings
Baseline patch state for the Linux kernel and generate exceptions when hosts exposing SR-IOV or vDPA remain on vulnerable versions

How to Mitigate CVE-2026-74712

Immediate Actions Required

Apply the upstream kernel patch that corrects the input length calculation in create_direct_keys() to all affected hosts
Restrict access to hypervisor hosts so that only trusted operators can attach or provision vDPA-backed guests
Audit which virtual machines are configured with vhost-vdpa and prioritize their host kernels for patching

Patch Information

The fix is available in the stable Linux kernel tree via the following commits: Kernel Git Commit 6c8a9f7bc003, Kernel Git Commit 727e1f569855, Kernel Git Commit cde8931a2539, and Kernel Git Commit ec3bb289cf19. Rebuild and reboot affected hosts against a kernel that includes these commits or apply the vendor's backported package once available.

Workarounds

Unload the mlx5_vdpa module on hosts that do not require vDPA acceleration using modprobe -r mlx5_vdpa
Blacklist mlx5_vdpa in /etc/modprobe.d/ on systems where the driver is not needed until patching completes
Migrate affected guests to hosts running patched kernels and drain unpatched hypervisors from production scheduling

bash

# Configuration example
# Verify current kernel and mlx5_vdpa module status
uname -r
lsmod | grep mlx5_vdpa

# Temporarily unload the vulnerable module
sudo modprobe -r mlx5_vdpa

# Persistently disable the module until the host is patched
echo 'blacklist mlx5_vdpa' | sudo tee /etc/modprobe.d/disable-mlx5-vdpa.conf
sudo update-initramfs -u