Hi On Mon, Jul 13, 2026 at 2:02 PM <[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(+) > > 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; > + }
I am dropping this block, it's already covered by earlier patch: https://patchew.org/QEMU/[email protected]/[email protected]/ > + > vs->client_pf.rmax = red_max ? red_max : 0xFF; > vs->client_pf.rbits = ctpopl(red_max); > vs->client_pf.rshift = red_shift; > -- > 2.55.0 > >
