Summary: | Division by zero in bmp_decompress_rle4() | ||
---|---|---|---|
Product: | MuPDF | Reporter: | Sebastian Rasmussen <sebastian.rasmussen> |
Component: | mupdf | Assignee: | MuPDF bugs <mupdf-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 1.24.0 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- |
Description
Sebastian Rasmussen
2024-02-28 13:14:10 UTC
Fixed in commit cee86dc519d5270a3b96476ad15809ceace64a26 Author: Sebastian Rasmussen <sebras@gmail.com> Date: Fri Mar 1 17:02:50 2024 +0800 Bug 707622: Add assert ensuring that image dimensions are > 0. CVE-2023-51105 reports that bmp_decompress_rle4() may end up in a division by zero. After deducing that the issue originates from clang's scan-build-17 and studying its reported issues, the source code of bmp_decompress_rle4(), bmp_read_bitmap(), and bmp_read_image(), were analyzed. bmp_read_image() already has checks that verify that image dimensions are > 0 and <= SHRT_MAX before calling bmp_read_bitmap(), which in case of compression calls either of bmp_decompress_rle4(), bmp_decompress_rle8(), bmp_decompress_rle24(), or bmp_decompress_huffman1d(). As expected, scan-build-17 complains similarly about division by zero reports in the rle8, rle24 and huffman1d functions. Why scan-build-17 can't realize that image dimensions have already been verified in bmp_read_image() is unclear. One way to avoid getting similar CVEs in the future is to add redundant assert()s for the image dimensions to the beginning of bmp_read_image() so they apply to all compression methods. After this scan-build-17's reports about division by zero in bmp_decompress_rle4() disappear and thus this eliminates CVE-2023-51105. |