Linux Kernel EUVD-2026-86644

Requires that the kernel be built with CONFIG_VDPA_SIM_NET and the vdpa_sim_net simulator module be loaded, and that the attacker have local access to a vhost-vdpa device instance (PR:L). Exploitation further requires inducing a TX vringh_iov_pull_iotlb() failure so the negative return is reinterpreted as a large RX length - a non-default, high-complexity condition (AC:H) not present against typical production kernels, which do not load this test/simulator driver. Not remotely reachable (AV:L) and requires no user interaction (UI:N).

This is a HIGH-CVSS-but-LOW-real-world-risk issue. NVD scores it 7.5 via CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:H, but multiple signals argue the effective priority is modest. The vector itself confirms LOCAL access (AV:L), HIGH complexity (AC:H - the bug lives on the TX-pull error path, which must be induced), and required privileges (PR:L - the attacker needs a usable vDPA device). There is no EPSS score, no CISA KEV listing, and no public exploit - exploitation status is 'no public exploit identified at time of analysis'. The affected code is vdpa_sim_net, a development/testing SIMULATOR driver, so the exposed attack surface is tiny in production. The scoring is internally questionable: S:C (scope change) is hard to justify for an in-kernel OOB that does not cross a defined security boundary, and C:H/I:N is an odd pairing - the description says a negative error 'can therefore become a large length in the RX path', which realistically produces an OOB access (crash/DoS, possibly a bounded read leak) rather than a clean high-confidentiality disclosure with zero integrity impact. Net: patch on normal kernel cadence; this is not an urgent, mass-exploitable flaw.

A local user with access to a vhost-vdpa device backed by the vdpa_sim_net simulator crafts virtqueue traffic that forces vringh_iov_pull_iotlb() to fail on the TX path, returning a negative value. That negative count is folded into an unsigned byte counter and passed as a large size_t length into the RX copy path (receive_filter / vringh_iov_push_iotlb), triggering an out-of-bounds access that crashes the kernel or reads adjacent memory. No public exploit code exists, and the high attack complexity plus reliance on the loaded simulator module and device access make opportunistic exploitation unlikely.