On Tue, Sep 1, 2026 at 7:54 PM Daniel P. Berrangé <[email protected]> wrote: > > On Mon, Aug 31, 2026 at 01:33:14PM +0200, Denis V. Lunev wrote: > > On 8/31/26 13:29, [email protected] wrote: > > >> A client which can reach a VNC websocket port crashes QEMU before it has > > >> authenticated, by sending an HTTP greeting whose request line holds no > > >> space: > > >> > > >> printf 'stats\r\nx\r\n\r\n' | nc $host $port > > >> > > >> Three defects line up to produce it. The greeting is rejected without > > >> queueing a response, so the handshake goes on to flush an empty buffer. > > >> A zero length sendmsg() succeeds and returns 0, which > > >> qio_channel_socket_writev() mistakes for failure and reports as > > >> QIO_CHANNEL_ERR_BLOCK with errp left unset. The handshake treats every > > >> negative return as fatal and hands that NULL Error to > > >> error_get_pretty(). Patches 1 to 3 close the three links. > > >> > > >> Patch 5 is the same NULL Error on the read side of the handshake, where > > >> ERR_BLOCK is folded into -1. It is reachable for a wss:// client, whose > > >> master channel is then a TLS channel: a wakeup carrying only part of a > > >> record makes gnutls report EAGAIN. > > >> > > >> The tests drive the handshake through a channel which reports ERR_BLOCK > > >> on demand, covering both directions. No test reproduces the original > > >> crash itself, which turns on a stale errno and is not reliably > > >> reproducible in a unit test. What they pin is that a 400 is emitted and > > >> that ERR_BLOCK no longer reaches error_get_pretty(). > > >> > > >> Signed-off-by: Denis V. Lunev <[email protected]> > > >> CC: Daniel P. Berrangé <[email protected]> > > >> CC: Marc-André Lureau <[email protected]> > > >> > > >> Denis V. Lunev (6): > > >> io/channel-socket: do not treat a zero length write as an error > > >> io/channel-websock: send an HTTP 400 when the greeting has no space > > >> io/channel-websock: handle a blocked write during the handshake > > >> tests/unit: add websock handshake test > > >> io/channel-websock: do not lose QIO_CHANNEL_ERR_BLOCK while reading > > >> tests/unit: cover blocked IO during the websock handshake > > >> > > >> io/channel-socket.c | 2 +- > > >> io/channel-websock.c | 10 +- > > >> tests/unit/meson.build | 1 + > > >> tests/unit/test-io-channel-websock.c | 249 +++++++++++++++++++++++++++ > > >> 4 files changed, 260 insertions(+), 2 deletions(-) > > >> create mode 100644 tests/unit/test-io-channel-websock.c > > >> > > > Patch series lgtm. You cc stable, why didn't you file a CVE? > > > > > > Reviewed-by: Marc-André Lureau <[email protected]> > > > > > I have calculated the scope and get around 6.2 which is > > not looking too impressive to spend a time. > > In the context of a VNC server enabling websocket. If we assume the > VNC server has authentication enabled, including the TLS extension > VeNCrypt, then the deployment can be said to be protecting against > a malicious client. > > The flaws mean the malicious client can inflict a denial of service > attack on the VM before getting to the VNC authentication step. IMHO > that is enough to justify a CVE assignment. > > CC'ing Mauro to double check my view & assign a CVE if appropriate
Agreed; a pre-auth VNC crash warrants CVE assignment. This is similar to https://access.redhat.com/security/cve/cve-2025-11234 Please use CVE-2026-84788 for this one. Thanks, > With regards, > Daniel > -- > |: https://berrange.com ~~ https://hachyderm.io/@berrange :| > |: https://libvirt.org ~~ https://entangle-photo.org :| > |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| > -- Mauro Matteo Cascella Red Hat Product Security
