summaryrefslogtreecommitdiffstats
path: root/README
diff options
context:
space:
mode:
authorWilly Tarreau <w@1wt.eu>2014-09-27 12:31:37 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2014-09-28 11:08:01 +0200
commit72cf90124e87d975d0b2114d930808c58b4c05e4 (patch)
treee258cacbf3bc33acf934d6b79e5d5b60248abb5f /README
parentaf958a38a60c7ca3d8a39c918c1baa2ff7b6b233 (diff)
downloadlinux-72cf90124e87d975d0b2114d930808c58b4c05e4.tar.bz2
lzo: check for length overrun in variable length encoding.
This fix ensures that we never meet an integer overflow while adding 255 while parsing a variable length encoding. It works differently from commit 206a81c ("lzo: properly check for overruns") because instead of ensuring that we don't overrun the input, which is tricky to guarantee due to many assumptions in the code, it simply checks that the cumulated number of 255 read cannot overflow by bounding this number. The MAX_255_COUNT is the maximum number of times we can add 255 to a base count without overflowing an integer. The multiply will overflow when multiplying 255 by more than MAXINT/255. The sum will overflow earlier depending on the base count. Since the base count is taken from a u8 and a few bits, it is safe to assume that it will always be lower than or equal to 2*255, thus we can always prevent any overflow by accepting two less 255 steps. This patch also reduces the CPU overhead and actually increases performance by 1.1% compared to the initial code, while the previous fix costs 3.1% (measured on x86_64). The fix needs to be backported to all currently supported stable kernels. Reported-by: Willem Pinckaers <willem@lekkertech.net> Cc: "Don A. Bailey" <donb@securitymouse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions