On Wed, Sep 17, 2025 at 10:38:29AM +0100, Daniel P. Berrangé wrote: > On Tue, Sep 16, 2025 at 09:41:53PM +0800, zoudongjie via wrote: > > When qemu is performing a TLS handshake for VNC, it will monitor vs->sioc > > in the qio_channel_tls_handshake_task. If the number of concurrent VNC > > connections exceeds the maximum number allowed by qemu, vnc_connect will > > traverse all connection requests in share mode VNC_SHARE_MODE_CONNECTING > > and disconnect the first one. > > > > If the disconnected request has not yet entered > > qio_channel_tls_handshake_io, > > it will cause the data pointer allocated in qio_channel_tls_handshake_task > > to leak directly, leading to an indirect leak of the task and its associated > > pointers. > > The qio_channel_tls_close method will cancel the pending handshake by > calling g_clear_handle_id. The problem is that when we do that, we fail > to release the QIOTask object because that is only freed when > qio_channel_tls_handshake is called on completion triggering use of > qio_task_complete. > > The problem here is that we broadly mis-used the APIs for sources... > > > @@ -201,13 +219,23 @@ static void > > qio_channel_tls_handshake_task(QIOChannelTLS *ioc, > > } > > > > trace_qio_channel_tls_handshake_pending(ioc, status); > > - ioc->hs_ioc_tag = > > - qio_channel_add_watch_full(ioc->master, > > - condition, > > - qio_channel_tls_handshake_io, > > - data, > > - NULL, > > - context); > > ...instead of NULL we should have passed a method that can free > the 'data' object there, as well as the QIOTask that 'data' > contains a reference to. > > The qio_task_complete method should not then free the task.
A fix for this flaw was implemented here: https://lists.nongnu.org/archive/html/qemu-devel/2026-01/msg00778.html With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
