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; + } + 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
