https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-51105 https://github.com/dongyuma/sox-defects/blob/main/mupdf-defects.md#1-a-floating-point-exception-divide-by-zero-issue-was-discovered-in-mupdf-in-functon-bmp_decompress_rle4-of-load-bmpc-in-line-541 A floating point exception (divide-by-zero) vulnerability was discovered in mupdf 1.23.4 in function bmp_decompress_rle4() of load-bmp.c.
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.