TigerVNC 1.14.0版本ZRLE解码错误分析与修复

在远程桌面协议实现中，TigerVNC作为一款高性能的VNC客户端/服务器软件，其1.14.0版本出现了一个值得注意的ZRLE（Zlib Run-Length Encoding）解码问题。该问题表现为当客户端连接运行RealVNC服务的Raspberry Pi设备时，会抛出"ZRLE decode error"异常，导致连接失败。

问题现象与背景

用户在使用Fedora 40系统上的TigerVNC 1.14.0客户端连接运行Bookworm系统的Raspberry Pi时遇到连接失败。错误日志显示ZRLE解码过程中出现异常，而回退到1.13.1版本则能正常工作。值得注意的是，即使强制使用RAW或Hextile编码方式，仍然会触发ZRLE相关的错误提示。

通过技术分析发现，这个问题与像素格式处理有关。错误发生在ZRLEDecoder处理调色板RLE数据时，可用数据长度（34字节）与预期长度（244字节）不匹配，表明存在数据解析错误。

根本原因

深入代码分析后发现问题出在ZRLEDecoder的像素格式判断逻辑上。在1.14.0版本中，baca73d03217a1c219d9c4f024ffcd39f85fd322提交引入的修改没有充分考虑像素深度（depth）的限制条件。具体表现为：

1. 对于32位像素格式（sizeof(T) == 4）的处理中，缺少对像素深度（depth ≤ 24）的检查
2. 这导致在某些端序（endianness）情况下错误地触发了特殊像素处理路径
3. 最终引发数据解析错误和长度计算错误

解决方案

项目维护者提出了一个精确定位的修复方案，通过增加像素深度检查来修正这个问题。关键修改如下：

bool isLowCPixel = (sizeof(T) == 4) && (pf.depth <= 24) &&
                  ((fitsInLS3Bytes && pf.isLittleEndian()) ||
                   (fitsInMS3Bytes && pf.isBigEndian()));
bool isHighCPixel = (sizeof(T) == 4) && (pf.depth <= 24) &&
                   ((fitsInLS3Bytes && pf.isBigEndian()) ||
                    (fitsInMS3Bytes && pf.isLittleEndian()));

这个修复确保了：

1. 只有在像素深度不超过24位时才应用特殊像素处理路径
2. 保持了原有的端序处理逻辑
3. 解决了与RealVNC服务器的兼容性问题

影响与验证

该修复已经过社区验证：

1. 成功解决了与Raspberry Pi上RealVNC服务的连接问题
2. 同时修复了远程光标显示异常的问题
3. 向后兼容性良好，不影响其他VNC服务器的连接

对于使用TigerVNC连接嵌入式设备（特别是Raspberry Pi）的用户，建议关注此修复并尽快升级到包含该修复的版本。该问题也提醒开发者在处理像素格式转换时需要特别注意深度和端序的组合情况，特别是在跨平台、跨实现的场景下。