Re: [PATCH 0/6] io/channel-websock: fix an unauthenticated crash in the handshake

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Aug 31, 2026 at 12:01:45PM +0200, Denis V. Lunev 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().


Thanks for the various fixes.

While we're on this topic though, way back when Websocket support was
first introduced to QEMU, I was pretty sceptical that it was a good
idea for QEMU to be implementing the HTTP protocol directly. Some of
these bugs (possibly even all) were likely a direct result of me
porting the websockets code into QIOChannel, so not neccessarily the
original impl.

None the less, I still feel pretty uncomfortable about the idea of
QEMU implementing websockets/HTTP support directly. The lack of
TLS support is a big flag that makes the whole thing questionable.
Although you could put TLS in at the VNC level with VeNCrypt,
IMHO doing it at the HTTP level is the right approach so the VNC
protocol handshake is fully covered.

Having it inside QEMU also means it missed the biggest benefit of
using websockets, which is that you can have a single TCP port
hosting all VMs and select them dynamically from the HTTP request,
instead of one TCP port per VM.

So I've thought about proposing its deprecation & deletion several
times, on the basis that it is better to put an external websockets
proxy in front of QEMU's VNC server instead of inside QEMU.


None the less, I'll queue all these patches.

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 :|