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