aboutsummaryrefslogtreecommitdiff
path: root/target-m68k/translate.c
diff options
context:
space:
mode:
authorMichael Tokarev <mjt@tls.msk.ru>2011-03-21 09:34:35 +0100
committerAurelien Jarno <aurelien@aurel32.net>2011-04-10 00:14:51 +0200
commit2caa9e9d2e0f356cc244bc41ce1d3e81663f6782 (patch)
tree99953fa95056b20126f245eca253aa548c1a4195 /target-m68k/translate.c
parenta88df0b9b517b76c1a0052fb1b0fe83080559197 (diff)
vnc: tight: Fix crash after 2GB of output
fix 2Gb integer overflow in in VNC tight and zlib encodings As found by Roland Dreier <roland@purestorage.com> (excellent catch!), when amount of VNC compressed data produced by zlib and sent to client exceeds 2Gb, integer overflow occurs because currently, we calculate amount of data produced at each step by comparing saved total_out with new total_out, and total_out is something which grows without bounds. Compare it with previous avail_out instead of total_out, and leave total_out alone. The same code is used in vnc-enc-tight.c and vnc-enc-zlib.c, so fix both cases. There, there's no actual need to save previous_out value, since capacity-offset (which is how that value is calculated) stays the same so it can be recalculated again after call to deflate(), but whole thing becomes less readable this way. Reported-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Diffstat (limited to 'target-m68k/translate.c')
0 files changed, 0 insertions, 0 deletions