Linux Kernel EUVD-2026-86169

Exploitation requires a host running the Linux kernel vhost-scsi backend (virtio-scsi with vhost offload, typically under KVM/QEMU) and local access to the vhost-scsi device to issue device ioctls. The attacker must have SCSI commands in flight and then trigger VHOST_SET_MEM_TABLE to replace the memory table before those asynchronously-completing commands finish, so the old response iovecs are reused. Limiting factors: local-only vector (AV:L), high attack complexity due to the narrow race window (AC:H), privilege to access the vhost-scsi device (PR:L), and the requirement that the host actually enables and uses the vhost-scsi target backend - a non-default, virtualization-specific configuration. Kernels before 6.12.111 / 6.18.53 / 7.2 (and the corresponding 6.x stable lines) are affected.

The provided CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H = 7.8 HIGH) frames this as a locally-triggered, high-complexity race condition requiring some privilege, with a scope change and high impact across confidentiality, integrity, and availability. The scope change (S:C) and impact ratings are what push it into HIGH territory. However, the signals are thin and partly conflicting: there is no EPSS score, no CISA KEV listing, and no public POC in the input, so this is no public exploit identified at time of analysis. The AC:H rating is well-justified - this is a genuine time-of-check/use race between the VHOST_SET_MEM_TABLE ioctl replacing the memory table and asynchronous target-core completion of in-flight commands still holding iovecs translated through the old table, so exploitation requires precise timing that is hard to win reliably. The realistic threat model is narrow: the actor needs access to the vhost-scsi character device (normally the host VMM/QEMU process, i.e. an already-privileged host component), not an arbitrary remote or unprivileged guest user, which supports PR:L and argues against treating this as a routine guest-to-host escape. Net: a legitimate correctness/hardening fix worth patching on KVM/QEMU virtualization hosts using the vhost-scsi backend, but NOT an urgent, widely-exploited priority - the combination of local vector, high attack complexity, niche subsystem, and absence of EPSS/KEV/POC signals means real-world risk is materially lower than the 7.8 headline suggests. Note the input Tag 'Information Disclosure' conflicts with the described behavior, which is a stray write of a command response to an unrelated userspace object (memory corruption / integrity), not primarily disclosure - verify impact framing against the kernel commit.

On a KVM host using the vhost-scsi backend, a guest keeps SCSI commands in flight while the host VMM issues VHOST_SET_MEM_TABLE (e.g. during memory hotplug or reconfiguration); an in-flight command still holding response iovecs translated through the now-replaced memory table completes and writes its SCSI response into an unrelated userspace object in the VMM address space, corrupting or exposing it. Winning this requires precise timing (AC:H) and access to the vhost-scsi device, and no public exploit code is identified at time of analysis.