QEMU CVE-2026-84788

Requires a QEMU instance using a socket-backed I/O channel (io/channel-socket) - such as TCP/UNIX socket chardevs, socket-based network backends, or the migration transport - where a write operation can return zero bytes. Exploitation is limited by the need to reach and drive such a channel into the zero-length-write condition, and the affected code path only matters for QEMU builds/versions predating this fix; whether the trigger is remotely reachable or requires a local/adjacent peer on the socket cannot be determined from the one-line description and must be confirmed against the upstream commit and Ubuntu advisory.

This CVE carries no CVSS score, no CVSS vector, and no CWE in the provided data, so any severity claim must be treated as inferred rather than confirmed. The description is a QEMU commit title - 'io/channel-socket: do not treat a zero length write as an error' - which points to a bug in QEMU's socket I/O channel layer (io/channel-socket.c) where a write returning zero bytes was incorrectly handled as an error condition rather than a benign/retryable case. This is characteristic of a robustness/correctness fix affecting connection handling, most plausibly leading to spurious I/O failures, dropped connections, or a denial-of-service edge case rather than memory corruption or code execution. There is no EPSS score, no CISA KEV listing, and no public exploit identified, which together argue against this being an active-exploitation priority. The only intelligence signal is the reporter 'vendor:ubuntu', indicating Ubuntu picked it up for tracking/patching - consistent with routine distro hardening of QEMU rather than an emergency. Bottom line: absent a CVSS vector, CWE, or exploitation data, this reads as a LOW-priority correctness/availability hardening fix; the impact class (DoS vs. functional bug) cannot be confirmed from the one-line description and should be verified against the upstream QEMU commit and any Ubuntu USN.

Under specific socket conditions, a peer or network event triggers a zero-length write on a QEMU socket I/O channel, which the unpatched code misinterprets as an error and aborts the channel, potentially disrupting a live migration stream, a chardev/network backend, or a monitor connection. No public exploit code is available, and the realistic outcome is a functional/availability disruption rather than attacker code execution. Exact triggerability and whether it is remotely inducible cannot be confirmed from the provided one-line description.