GHSA-wpp4-vqfq-v4hp ImageMagick CLAHE : Unsigned underflow and division-by-zero lead to OOB pointer arithmetic and process crash (DoS)
SummaryA single root cause in the CLAHE implementation — tile width/height becoming zero — produces two distinct but related unsafe behaviors.
Vulnerabilities exists in the `CLAHEImage()` function of ImageMagick’s `MagickCore/enhance.c`.Unsigned integer underflow → out-of-bounds pointer arithmetic (OOB): when `tile_info.height == 0`, the expression `tile_info.height - 1` (unsigned) wraps to a very large value; using that value in pointer arithmetic yields a huge offset and OOB memory access (leading to memory corruption, SIGSEGV, or resource exhaustion).**Division/modulus by zero**: where code performs `... / tile_info.width` or `... % tile_info.height` without re-checking for zero, causing immediate division-by-zero crashes under sanitizers or `abort` at runtime.Both behaviors are triggered by the same invalid tile condition (e.g., CLI exact `-clahe 0x0!` or automatic tile derivation `dim >> 3 == 0` for very small images).Details**Unsigned underflow(can lea to OOB)**Location: `MagickCore/enhance.c`, around line 609Version tested: 7.1.2-8 (local ASan(undefined). /UBSan build)Vulnerable codeenhance.c: 609Root CauseIf `tile.height == 0`, then `(tile.height - 1)` underflows to `UINT_MAX`.Multiplication with `clahe_info->width` yields a huge value close to `SIZE_MAX`.Adding this to `p` causes pointer arithmetic underflow.**Division-by-zero**File / Location: `MagickCore/enhance.c`, around line 669Version tested: 7.1.2-8 (local ASan(undefined). /UBSan build)vulnerable codeenhance.c: 669-673Root causeMissing input validation / bounds checks after computing default tile dimensions:If either `tile_info.width` or `tile_info.height` is 0, this triggers a division by zero. Zeros can reach this point through:Exact tiles: CLI `clahe 0x0!` (the `!` forces zero to be used verbatim).Auto tiles on tiny images: When a requested tile is `0` (no `!`), the code derives a default from the image size (e.g., `dim >> 3`). For images with `dim < 8`, this result is 0 unless clamped.Reproduction**Unsigned underflow****Environment**Built with AddressSanitizer and UndefinedBehaviorSanitizer enabled.**Command****Output**`./magick -size 10x10 xc:black -clahe 0x0 null:`memory region corruption.`./magick -size 2000x2000 xc:black -clahe 0x0 null:`→ Significant memory consumption and evidence of memory region corruption.`./magick -size 4000x4000 xc:black -clahe 0x0 null:`→ Much larger memory usage; process appears to be aggressively consuming cache and address space.`./magick -size 8000x8000 xc:black -clahe 0x0 null:`→ Memory usage escalates further and begins exhausting available cache. If left running, the process is likely to crash (DoS) after sustained allocation attempts.**Division-by-zero****Environment:** ASan/UBSan-enabled build.**Command****Output****Notes:** Without sanitizers, the process may terminate with just `Aborted` (still DoS).ImpactPrimary: Denial-of-Service — crash or sustained resource exhaustion (memory/cache thrash) when processing crafted parameters or small images via CLI or API. Attackers can trivially trigger via `clahe 0x0!` or by uploading very small images to services using ImageMagick.Secondary (theoretical): OOB memory accesses and memory corruption could potentially be combined with other vulnerabilities to achieve more severe outcomes; however, no reliable code execution was demonstrated from these PoCs alone.Suggested concrete patch snippetsApply in `CLAHEImage()` after `tile_info` is computed but **before** any division/modulus/pointer arithmetic:Notes about `exact_tiles_requested`: if the CLI/Wand parser already exposes whether `!` was present, use it. If not, add a parse-time flag so CLAHEImage can know whether `0` is literal or auto.CreditTeam Whys**Bug Hunting Master Program, HSpace/Findthegap****Youngmin Kim** 
kunshim@naver.com**Woojin Park**[@jin-156](https://github.com/jin-156)
[1203kids@gmail.com](mailto:1203kids@gmail.com)**Youngin Won**[@amethyst0225](https://github.com/amethyst0225)
[youngin04@korea.ac.kr](mailto:youngin04@korea.ac.kr)**Siyeon Han**[@hanbunny](https://github.com/hanbunny)
[kokosyeon@gmail.com](mailto:kokosyeon@gmail.com)**Shinyoung Won**[@yosiimich](yosimich123@gmail.com)
[yosimich123@gmail.com](mailto:yosimich123@gmail.com)
CVSS v3.1 score: 4.7