Skip to content

CVE-2020-22524 - Fix integer overflow leading to undersized allocation in PFM loader - #56

Merged
danoli3 merged 2 commits into
masterfrom
fix/pfm-overflow-allocation
Aug 16, 2026
Merged

CVE-2020-22524 - Fix integer overflow leading to undersized allocation in PFM loader#56
danoli3 merged 2 commits into
masterfrom
fix/pfm-overflow-allocation

Conversation

@danoli3

@danoli3 danoli3 commented Aug 14, 2026

Copy link
Copy Markdown
Owner

Load() computed the PFM line buffer size as 3 * width (int/unsigned), where width comes straight from the file header with only a <= 0 check — no upper bound. Past ~715M, 3 * width overflows the 32-bit multiply and wraps small, so malloc() undersizes lineBuffer while the unpack loop right below still iterates the original, un-overflowed width — reading/writing past the end of it.

Computes the line width in size_t instead, so the multiply can't overflow before it reaches malloc().

CVE Link
CVE-2020-22524 https://nvd.nist.gov/vuln/detail/CVE-2020-22524

Fixes: CVE-2020-22524

…VE-2020-22524)

Load() computed the RLE/pixel line buffer size as
`const unsigned lineWidth = 3 * width;` (RGBF) or `= width;` (FLOAT),
where width is an int read directly from the PFM header with no upper
bound (only `width <= 0` is rejected). For the RGBF case in particular,
`3 * width` is evaluated as a 32-bit signed int multiply before being
stored into lineWidth, so a sufficiently large width (~715M+) silently
overflows and wraps to a small value.

malloc(lineWidth * sizeof(float)) then succeeds with a buffer far
smaller than the real per-scanline size, while the pixel-unpacking
loop right below it still iterates `for (x = 0; x < width; x++)`
against the original, un-overflowed width - reading/writing past the
end of that undersized lineBuffer.

Compute lineWidth in size_t instead, so the multiply can't overflow
before it reaches malloc(); genuinely unreasonable widths now just
fail malloc() cleanly, which Load() already handles via the existing
`if(!lineBuffer) throw FI_MSG_ERROR_MEMORY` check.

CWE-190 (Integer Overflow) leading to CWE-787/CWE-125 (Out-of-bounds
Write/Read)

Fixes: CVE-2020-22524
The previous commit's edit was re-serialized as UTF-8, corrupting the
file's original ISO-8859-1 "Hervé Drolon" byte sequence into a
replacement character. Restore it by converting the original file to
UTF-8 properly rather than accidentally.
@danoli3
danoli3 force-pushed the fix/pfm-overflow-allocation branch from d3bbac1 to 6ac71b4 Compare August 16, 2026 08:29
@danoli3
danoli3 merged commit bcdb3af into master Aug 16, 2026
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant