integer overflow in PNM size check bypasses memory guard (_load_pnm)

[JorgeBarredo14]

The size check in _load_pnm compares the declared pixel count against the file size, but the multiplication is done in unsigned int and wraps at
2^32. Oversized images go through, then assign() uses 64-bit arithmetic and tries to allocate the full huge size.

Current code (CImg.h around line 57390 and 57428 in _load_pnm):

unsigned int ppm_type, W, H, D = 1, colormax = 255;
// ... W, H, D parsed from the ASCII header ...
const cimg_int64 siz = cimg::fsize(filename);
if (W*H*D > siz)                   // unsigned int overflow here
    throw CImgIOException(...);
assign(W, H, D, channels);         // safe_size is 64-bit, sees the real size

With W = 65536, H = 65537, D = 1:

W*H*D as unsigned int = 65536 * 65537 = 0x100010000 -> wraps to 65536
65536 > siz -> false for any file >= 64KB, so check passes
assign(65536, 65537, 1, 1) allocates 4,295,032,832 bytes -> OOM

CVE-2020-25693 was the integer overflow in _load_pnm fixed in 2.9.3. The fix there added 64-bit checks inside assign/safe_size, but this earlier pre-assign guard was left in 32-bit. So the guard is still bypassable on current master (commit 3de5134, version 3.7.5-pre).

To Reproduce

Attached PoC: poc_pnm_intoverflow.pgm (65,556 bytes).

Header: P5\n65536 65537\n255\n followed by 65537 bytes of pixel data. Load with CImg().load_pnm(path).

ASan output:

ERROR: libFuzzer: out-of-memory (malloc(4295032832))
    #8  in cimg_library::CImg<unsigned char>::assign() CImg.h:13579
    #9  in cimg_library::CImg<unsigned char>::_load_pnm() (via assign)

Expected behavior

Reject the image, same as the internal safe_size does when it is reached directly.

Fix idea

--- a/CImg.h
+++ b/CImg.h
@@ -57425,7 +57425,7 @@
     const cimg_int64 siz = cimg::fsize(filename);
-    if (W*H*D > siz)
+    if ((cimg_int64)W*H*D > siz)
         throw CImgIOException(_cimg_instance
                               "load_pnm(): File size (%lld) inconsistent with "
                               "image dimensions (%u,%u,%u).",
                               cimg_instance,
                               (long long)siz,W,H,D);

Same pattern (unsigned int multiplication against a 64-bit size) is worth checking in the other ASCII/binary loaders (pandore, inr, etc.).

poc_pnm_intoverflow.zip

[dtschump]

Thanks! Commit 4ca26bc does what you suggest.

[JorgeBarredo14]

Thanks! Commit 4ca26bc does what you suggest.

Hi David, thank you for the quick fix. Would you consider opening a GitHub Security Advisory for these two issues so a CVE can be assigned? I am happy to provide the CVSS scores and CWE references if helpful.

[dtschump]

I'm not against the idea, but this looks rather complicated to fill in (at least for me), and I've not much time to look at it.
Could you suggest a way to do it ? (same for the other issue)
Thanks!

Advisory Details
Title *

CVE identifier

After you create your draft advisory, GitHub can assign a CVE ID to your repository security advisory prior to public disclosure. Once you publish the advisory, GitHub publishes the CVE details.
Description *
### Impact
_What kind of vulnerability is it? Who is impacted?_

### Patches
_Has the problem been patched? What versions should users upgrade to?_

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

### References
_Are there any links users can visit to find out more?_
Affected products

Ecosystem

Package name

Affected versions

Patched versions

Severity
Unknown
Pending selection
Severity
Vector string
Calculator

Weaknesses
Common weakness enumerator (CWE)
Credits

[JorgeBarredo14]

I'm not against the idea, but this looks rather complicated to fill in (at least for me), and I've not much time to look at it. Could you suggest a way to do it ? (same for the other issue) Thanks!

Advisory Details
Title *

CVE identifier

After you create your draft advisory, GitHub can assign a CVE ID to your repository security advisory prior to public disclosure. Once you publish the advisory, GitHub publishes the CVE details.
Description *
### Impact
_What kind of vulnerability is it? Who is impacted?_

### Patches
_Has the problem been patched? What versions should users upgrade to?_

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

### References
_Are there any links users can visit to find out more?_
Affected products

Ecosystem

Package name

Affected versions

Patched versions

Severity
Unknown
Pending selection
Severity
Vector string
Calculator

Weaknesses
Common weakness enumerator (CWE)
Credits

Hi David, happy to help — here is the exact text to paste into each field, for both issues:

ISSUE #478 — PNM integer overflow

Advisory Details
Title *
Integer overflow in PNM size check bypasses memory guard (_load_pnm)

CVE identifier
(GitHub will assign automatically)

Description *
### Impact
Integer overflow in the `W*H*D` size computation inside `_load_pnm()` can bypass
the memory allocation guard. A crafted PNM/PGM/PPM file with large dimension values
causes the overflow to wrap around, allocating an undersized buffer and potentially
triggering a heap buffer overflow. Any application using CImg to load untrusted
image files is affected.

### Patches
Fixed in commit 4ca26bc. Users should update to the latest master.

### Workarounds
Do not load untrusted PNM/PGM/PPM files with CImg.

### References
https://github.com/GreycLab/CImg/issues/478

Affected products
Ecosystem: Other
Package name: CImg
Affected versions: < 4ca26bc
Patched versions: >= 4ca26bc

Severity
Vector string: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H

Weaknesses
Common weakness enumerator (CWE): CWE-190

Credits
Jorge Barredo Ferreira

---

ISSUE #477 — BMP nb_colors OOM

Advisory Details
Title *
Uncontrolled memory allocation via nb_colors field in _load_bmp

CVE identifier
(GitHub will assign automatically)

Description *
### Impact
The `nb_colors` field read from the BMP file header is used directly to compute
an allocation size without validating it against the remaining file size. A crafted
BMP file with a large `nb_colors` value triggers an out-of-memory condition,
crashing any application that uses CImg to load untrusted BMP files.

### Patches
Fixed in commit c3aacf5. Users should update to the latest master.

### Workarounds
Do not load untrusted BMP files with CImg.

### References
https://github.com/GreycLab/CImg/issues/477

Affected products
Ecosystem: Other
Package name: CImg
Affected versions: < c3aacf5
Patched versions: >= c3aacf5

Severity
Vector string: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Weaknesses
Common weakness enumerator (CWE): CWE-789

Credits
Jorge Barredo Ferreira

Thank you David, just paste the content above into each field and hit "Create draft" — GitHub will handle the CVE assignment automatically once you publish.

[dtschump]

Thanks @JorgeBarredo14 .
I've created the two entries.

[JorgeBarredo14]

Hi @dtschump, thanks for creating the advisories. Would it be possible to add me as credited reporter in both GHSAs? Thanks either way.

[dtschump]

Ha yes sorry, I've copy/pasted your name but realized only afterwards that I should have entered your github login.

[JorgeBarredo14]

No worries :) Thank you