All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH] io: prevent unbounded read of websocket data from client
Date: Wed, 30 Sep 2026 09:27:06 +0100	[thread overview]
Message-ID: <arzH2idk9MDVbSKx@redhat.com> (raw)
In-Reply-To: <CAJ+F1C+CqVB45HLPNaiwJJjbnrmwNAkDu=kGN=Ut8OsBW4VdYA@mail.gmail.com>

On Tue, Sep 29, 2026 at 12:09:35AM +0400, Marc-André Lureau wrote:
> On Mon, Sep 28, 2026 at 5:09 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > The QIOChannelWebsock class wraps an underlying QIOChannel instance,
> > providing a websocket server handshake and packet encoding/decoding.
> >
> > When a watch is added to QIOChannelWebsock, this in turn creates a watch
> > on the underlying QIOChannel that is always monitoring G_IO_IN, as long
> > as the 'encinput' buffer has space.
> >
> > When this watch fires, it reads data off the wire into 'encinput' and
> > then decodes as much of 'encinput' as possible into the 'rawinput'
> > buffer.
> >
> > The qio_channel_websock_set_watch method checks to see that 'encinput'
> > does not exceed a max limit, but fails to check that 'rawinput' size.
> > Since any data read into 'encinput', can usually be immediately decoded
> > into 'rawinput', the 'encinput' size check is largely a no-op, and so
> > 'rawinput' will grow without bound.
> >
> > This is readily seen with the chardev socket backend if enabling
> > websockets, connecting a client that sends data, while not running any
> > guest OS to consume data from the chardev via a virtual serial port.
> >
> > The qio_channel_websock_read_wire() method will also unconditionally
> > read more data into 'encinput' if it has less than 4k present, which
> > is then decoded into 'rawinput'.
> >
> > IOW, if qio_channel_websock_read_wire() is triggered for lots of small
> > reads, it will be reading and decoding more data to 'rawinput' than is
> > consumed. Skip reading more data if 'rawinput' is already at its max
> > size.
> >
> > Reported-by: Aisle Research
> > Fixes: CVE-2026-101291
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> 
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> 
> not sure if it's worth to add:
> Fixes: 2d1d0e70cf3e ("io: add QIOChannelWebsock class")

Doesn't hurt, so might as well.

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



      parent reply	other threads:[~2026-09-30  8:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 13:09 [PATCH] io: prevent unbounded read of websocket data from client Daniel P. Berrangé
2026-09-28 20:09 ` Marc-André Lureau
2026-09-29  5:02   ` Philippe Mathieu-Daudé
2026-09-30  8:27   ` Daniel P. Berrangé [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=arzH2idk9MDVbSKx@redhat.com \
    --to=berrange@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.