Submit #914948: Matthias-Wandel jhead v3.3 (commit 5007491, 3.08-66-g5007491) heap-buffer-overflow (Get32u)

Affected Versions
jhead commit 5007491 (3.08-66-g5007491): reproduced with AddressSanitizer. This is the repository HEAD at the time of the report.
The version is annotated as v3.3 (commit 5007491, 3.08-66-g5007491) in the public report.
As of the submission material date (2026-08-04), no upstream fix commit exists. No fixed release is identified. The status should be updated once the maintainer merges a fix.

Classification
Attack type: Local
Attack complexity: Low
Privileges required: None
User interaction: Required
Exploit availability: Public proof-of-concept
Proven impact: Application crash and loss of availability (out-of-bounds read)
Suggested severity: Medium
CVSS 3.1 score: 5.5
CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Technical Description
jhead is affected by a heap buffer out-of-bounds read while parsing the GPS sub-directory of a crafted WebP file's EXIF chunk. In ProcessGpsInfo (gpsinfo.c:144), GPS latitude/longitude rational denominators are read with den = Get32s(ValuePtr+4+a*ComponentSize) without validating that the value pointer plus the read size lies within the valid EXIF buffer range [OffsetBase, OffsetBase+ExifLength).

A malformed EXIF GPS sub-directory allows an attacker-controlled ValuePtr to land past the allocated buffer. Get32s (exif.c:341) then reads 4 bytes past the end of the region, producing a 4-byte out-of-bounds read. AddressSanitizer reports the heap-buffer-overflow and aborts jhead, causing denial of service when a user or automated image-processing workflow parses the malicious WebP file. No special command-line flags are required to trigger the bug.

The public report notes this may be an incomplete fix for jhead issue #62. The proven impact is an out-of-bounds read and process crash. The submission does not assert demonstrated confidentiality disclosure, code execution, or privilege escalation.

Proof of Concept
PoC archive: issue-99_poc.zip PoC URL: https://github.com/user-attachments/files/30397094/poc.zip

The PoC is a 4208-byte malformed WebP file with a crafted EXIF GPS sub-directory that causes ValuePtr to point past the buffer boundary.

Command:

# Build with AddressSanitizer
CC=afl-clang-fast CFLAGS="-fsanitize=address" make

# Trigger the crash (no special flags needed)
ASAN_OPTIONS="detect_leaks=0:halt_on_error=1" ./jhead poc.bin
Observed sanitizer result:

==1658674==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61e000000baa
READ of size 1 at 0x61e000000baa thread T0
#0 in Get32s exif.c:341
#1 in ProcessGpsInfo gpsinfo.c:144
#2 in ProcessExifDir exif.c:892
#3 in process_EXIF exif.c:1063
#4 in ReadWebpSections webpfile.c:129
#5 in ReadImgFile imgfile.c:76
#6 in ProcessFile jhead.c:491
#7 in main jhead.c:1150

0x61e000000baa is located 4 bytes to the right of 2854-byte region [0x61e000000080,0x61e000000ba6)
SUMMARY: AddressSanitizer: heap-buffer-overflow exif.c:341 in Get32s
==1658674==ABORTING
Root Cause
ProcessGpsInfo reads GPS rational values through a ValuePtr derived from EXIF directory entry offsets, but does not verify that ValuePtr + read_size stays within [OffsetBase, OffsetBase+ExifLength). The main directory bounds check does not cover this GPS value-access path, so a crafted GPS sub-directory can position ValuePtr beyond the buffer and trigger a 4-byte out-of-bounds read inside Get32s.

Countermeasure
As of 2026-08-04 the upstream issue is still open and no fix commit is available. Environments that cannot wait for an upstream fix should:

Avoid processing untrusted WebP/EXIF files with the affected jhead build.
Run jhead in a sandboxed, low-privilege environment with resource limits.
Apply process timeouts, crash isolation, and failed-file quarantine for automated pipelines.
Pre-validate or transcode inputs with a trusted image library before invoking jhead.
Suggested fix direction: validate ValuePtr + read_size <= OffsetBase + ExifLength before any EXIF value read in ProcessGpsInfo and all other EXIF value-access paths, so that the GPS sub-directory cannot bypass the main directory range check.

This entry should be updated with the fix commit and fixed release once the maintainer merges a patch.

• Quelle: ⚠️ https://github.com/Matthias-Wandel/jhead/issues/99
• Benutzer: fczhang (UID 97720)
• Einreichung: 04.08.2026 15:51 (vor 1 Monat)
• Moderieren: 13.09.2026 06:48 (1 month later)
• Status: Akzeptiert
• VulDB Eintrag: 403215 [Matthias-Wandel jhead bis 3.3 WebP EXIF gpsinfo.c ProcessGpsInfo TAG_GPS_LAT/TAG_GPS_LONG Pufferüberlauf]
• Punkte: 20