When a VNC client sends a "set pixel format" message, the
'client_endian' field will get initialized, however, it is
valid to omit this message if the client wants to use the
server's native pixel format. In the latter scenario nothing
is initializing the 'client_endian' field, so it remains set
to 0, matching neither G_LITTLE_ENDIAN nor G_BIG_ENDIAN. This
then results in pixel format conversion routines taking the
wrong code paths.
This problem existed before the 'client_be' flag was changed
into the 'client_endian' value, but the lack of initialization
meant it semantically defaulted to little endian, so only big
endian systems would potentially be exposed to incorrect pixel
translation.
The 'virt-viewer' / 'remote-viewer' apps always send a "set
pixel format" message so aren't exposed to any problems, but
the classical 'vncviewer' app will show the problem easily.
Fixes: 7ed96710e82c385c6cfc3d064eec7dde20f0f3fd
Reported-by: Thomas Huth <th...@redhat.com>
Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
---
ui/vnc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ui/vnc.c b/ui/vnc.c
index d095cd7da3..51872d1838 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2329,6 +2329,7 @@ static void pixel_format_message (VncState *vs) {
char pad[3] = { 0, 0, 0 };
vs->client_pf = qemu_default_pixelformat(32);
+ vs->client_endian = G_BYTE_ORDER;
vnc_write_u8(vs, vs->client_pf.bits_per_pixel); /* bits-per-pixel */
vnc_write_u8(vs, vs->client_pf.depth); /* depth */
--
2.49.0
