On Mon, Jul 13, 2026 at 02:00:56PM +0400, [email protected] wrote: > From: Marc-André Lureau <[email protected]> > > The VNC SetPixelFormat message carries red/green/blue_max as 16-bit > values, but PixelFormat stores them as uint8_t. A client sending a > max value above 255 (e.g. 0x0100) passes the existing non-zero check > but silently truncates to 0 on assignment, leading to a division by > zero in the Tight PNG palette path. > > Similarly, the shift values are read as uint8_t from the wire but > used in left-shift expressions (red_max << red_shift). Shifts >= 32 > are undefined behavior in C for 32-bit operands. > > Add explicit range checks for both: reject the connection if any > channel max exceeds UINT8_MAX, or any shift is >= 32. > > Fixes: CVE-2026-15578 > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3976 > Reported-by: dong ling > Signed-off-by: Marc-Andre Lureau <[email protected]> > --- > ui/vnc.c | 10 ++++++++++ > 1 file changed, 10 insertions(+)
Reviewed-by: Daniel P. Berrangé <[email protected]> > > diff --git a/ui/vnc.c b/ui/vnc.c > index dfc8262d42a..c4ee4738b28 100644 > --- a/ui/vnc.c > +++ b/ui/vnc.c > @@ -2276,6 +2276,16 @@ static void set_pixel_format(VncState *vs, int > bits_per_pixel, > return; > } > > + if (red_max > UINT8_MAX || green_max > UINT8_MAX || blue_max > > UINT8_MAX) { > + vnc_client_error(vs); > + return; > + } > + > + if (red_shift >= 32 || green_shift >= 32 || blue_shift >= 32) { > + vnc_client_error(vs); > + return; > + } > + > vs->client_pf.rmax = red_max ? red_max : 0xFF; > vs->client_pf.rbits = ctpopl(red_max); > vs->client_pf.rshift = red_shift; 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 :|
