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
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 <den@openvz.org> CC: Daniel P. Berrangé <berrange@redhat.com> CC: Marc-André Lureau <marcandre.lureau@redhat.com> 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 -- 2.53.0
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 :|
> 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 <den@openvz.org> > CC: Daniel P. Berrangé <berrange@redhat.com> > CC: Marc-André Lureau <marcandre.lureau@redhat.com> > > 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 <marcandre.lureau@redhat.com> -- Marc-André Lureau <marcandre.lureau@redhat.com>
On 8/31/26 13:29, marcandre.lureau@redhat.com 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 <den@openvz.org> >> CC: Daniel P. Berrangé <berrange@redhat.com> >> CC: Marc-André Lureau <marcandre.lureau@redhat.com> >> >> 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 <marcandre.lureau@redhat.com> > I have calculated the scope and get around 6.2 which is not looking too impressive to spend a time. There are toooooo many CVEs circulating around :-) If this is wrong approach - let me know. I'll change the approach. Thanks for review, Den
On Mon, Aug 31, 2026 at 01:33:14PM +0200, Denis V. Lunev wrote: > On 8/31/26 13:29, marcandre.lureau@redhat.com 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 <den@openvz.org> > >> CC: Daniel P. Berrangé <berrange@redhat.com> > >> CC: Marc-André Lureau <marcandre.lureau@redhat.com> > >> > >> 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 <marcandre.lureau@redhat.com> > > > 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 :|
On Tue, Sep 1, 2026 at 7:54 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Mon, Aug 31, 2026 at 01:33:14PM +0200, Denis V. Lunev wrote: > > On 8/31/26 13:29, marcandre.lureau@redhat.com 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 <den@openvz.org> > > >> CC: Daniel P. Berrangé <berrange@redhat.com> > > >> CC: Marc-André Lureau <marcandre.lureau@redhat.com> > > >> > > >> 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 <marcandre.lureau@redhat.com> > > > > > 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
© 2016 - 2026 Red Hat, Inc.