heap-buffer-overflow (underflow) in parseIFEntry_temp via crafted JPEG - ASan verified

[Sheri98]

Description

heap-buffer-overflow (READ) in parseIFEntry_temp when parsing crafted JPEG files
with malformed EXIF data. The function reads 1 byte before the start of a heap-allocated
buffer (heap buffer underflow) at exif.cpp line 350.

To Reproduce

1. Compile the PoC with AddressSanitizer
2. Load the attached crafted JPEG (294 bytes)
3. ASan detects heap-buffer-overflow at exif.cpp line 350

PoC Code

#include <cstdio>
#include <vector>
#include "exif.h"

int main(int argc, char *argv[]) {
    FILE *f = fopen(argv[1], "rb");
    fseek(f, 0, SEEK_END);
    long sz = ftell(f);
    fseek(f, 0, SEEK_SET);
    std::vector<unsigned char> buf(sz);
    fread(buf.data(), 1, sz, f);
    fclose(f);

    easyexif::EXIFInfo result;
    result.parseFrom(buf.data(), (unsigned)buf.size());
    return 0;
}

Build: cl /EHsc /fsanitize=address poc_exif.cpp exif.cpp

ASan Output

Root Cause

In parseIFEntry_temp (exif.cpp:350), the EXIF IFD entry parser computes an
offset from the EXIF buffer without validating that it falls within bounds.
A crafted JPEG with malformed EXIF IFD entries causes the parser to read 1 byte
before a heap allocation (underflow). The read byte comes from heap metadata or
adjacent freed memory, and influences how the IFD entry is interpreted.

Impact

• Information disclosure (heap data leaked via out-of-bounds read)
• Crash/DoS (if read crosses into unmapped memory)
• Corrupted EXIF values returned to the application (GPS, timestamps, etc.)
• Affects all applications using easyexif to parse EXIF from untrusted JPEGs
• Used in CactusViewer and other image processing applications

Fix Suggestion

Add bounds checking in parseIFEntry_temp to validate that all computed
offsets fall within the valid buffer range before performing reads.

Environment

• easyexif latest (master branch)
• Windows 11 x64, MSVC 19.50
• Found via mutation-based fuzzing with AddressSanitizer

Image -