0day: libpng APNG OOB Write

1. APNG write merged late. PNG_APNG_SUPPORTED + PNG_WRITE_APNG_SUPPORTED came into libpng's mainline through the libpng18 branch (post-v1.6.58). Vanilla libpng 1.6.x distributions without the APNG patch are not affected.
2. OSS-Fuzz historically pressures the read side. The standard fuzz target libpng_read_fuzzer.cc exercises decode. The per-frame APNG write API is only reachable through a harness that explicitly drives png_write_frame_head / png_write_rows / png_write_frame_tail in a loop.
3. The trigger pattern is structural. The bug fires only when per-frame fcTL widths vary across an APNG - specifically, when a narrower frame is followed by a wider one. Generators that emit uniform-width APNGs (the common case) miss the bug class entirely.

The campaign's 50+ semantic mutation strategies in png_semantic_mutator.py included one - apng_fctl_geometry - that perturbed per-frame widths independently. That single strategy is what surfaced the canonical 4,4,4,3,1,4,4,4 width-sequence reproducer.

One defect, two symptoms

Findings 002 and 003 are a single defect: png_write_reset does not release the per-frame scratch buffers. With uniform frame widths that shows up as a clean memory leak; with varying widths it becomes an out-of-bounds write. One patch closes both, so the advisory treats them as one independently-fixable vulnerability mapping to one CVE. A third finding from the same campaign - sub-byte pad-bit propagation (CWE-908) - is spec-compliant, was removed from the advisory as a hardening item, and is not closed by this patch.

Root Cause - Memory Leak (Finding 002, CWE-401)

png_write_reset (pngwutil.c:2884) is called from png_write_frame_head to begin each new APNG frame. It zeros three frame-progress fields - row_number, pass, and a mode flag - but does not free row_buf, prev_row, try_row, or tst_row. Because the counters are zeroed, the next png_write_row call re-enters the first-row init path and png_write_start_row runs again. It reallocates row_buf unconditionally, and prev_row whenever the frame's filter set includes AVG, UP, or PAETH - in both cases overwriting the pointer without freeing what it held. (try_row and tst_row are guarded on try_row == NULL, so they survive instead; that is the path Variant A trips.) Every frame silently leaks its scratch allocation.

Direct leak of 26 byte(s) in 2 object(s) allocated from:
  #1 png_malloc_base                  pngmem.c:98
  #3 png_calloc                       pngmem.c:54
  #4 png_write_start_row              pngwutil.c:2096   <- prev_row
  #5 png_write_row                    pngwrite.c:812

Direct leak of 26 byte(s) in 2 object(s) allocated from:
  #1 png_malloc_base                  pngmem.c:98
  #3 png_write_start_row              pngwutil.c:2049   <- row_buf
  #4 png_write_row                    pngwrite.c:812

SUMMARY: AddressSanitizer: 52 byte(s) leaked in 4 allocation(s).

The leak grows linearly with frame count. num_frames is capped at PNG_UINT_31_MAX (0x7fffffff); combined with typical row-bytes in the kilobytes, an attacker can leak megabytes per re-encode call. Against a long-running process that re-encodes APNG through the per-frame write API, that is slow heap-pressure DoS - subject to the same narrow reachability as the overflow, which is covered below.

OOB Write Mechanics (Finding 003, CWE-787)

My original report explained this as row_buf simply being left sized for the narrower frame. The maintainer instrumented it during triage and showed that is not what happens: png_write_start_row does fire on every frame, and it does allocate row_buf at the correct size for that frame. The stale buffer arrives by a different route, and the corrected mechanism is the one below.

The trigger is the filter double-buffer. png_write_filtered_row swaps row_buf and prev_row after each row, so the two pointers trade places as a frame is written out; png_write_reset frees neither. A narrow intermediate frame's small row_buf is swapped into prev_row and survives there across the frame boundary. On the second row of a later, wider frame, the swap puts that stale narrow buffer back into row_buf - and the row memcpy at pngwrite.c:900 writes the wide frame's row into it:

memcpy(png_ptr->row_buf + 1, row, row_info.rowbytes)

The write is row_info.rowbytes - that is PNG_ROWBYTES(usr_pixel_depth, current_width), 12 bytes for a 4-pixel RGB8 row - starting at row_buf + 1, into an allocation sized for the narrow frame. The wide frame's first row is fine; a later row is where it lands, so a single-row wide frame will not trip it. The mismatch is otherwise geometric: independent of color type, bit depth, and interlace type.

The canonical trigger is an 8-frame RGB8 APNG with fcTL widths 4,4,4,3,1,4,4,4: three full-width frames, two progressively narrower frames, then growth back to full width. The OOB fires on the first wide post-narrow frame.

==21987==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000065a
WRITE of size 12 at 0x60200000065a thread T0
    #0 __asan_memcpy
    #1 png_write_row              pngwrite.c:900:4
    #2 png_write_rows             pngwrite.c:651:7
    #3 LLVMFuzzerTestOneInput     apng_write_fuzzer.c:473:17

0x60200000065a is located 0 bytes to the right of 10-byte region [0x602000000650,0x60200000065a)
allocated by thread T0 here:
    #0 malloc
    #1 png_malloc_base            pngmem.c:98:11
    #2 png_malloc                 pngmem.c:181:10
    #3 png_write_start_row        pngwutil.c:2049:23
    #4 png_write_row              pngwrite.c:812:7
    #5 png_write_rows             pngwrite.c:651:7

SUMMARY: AddressSanitizer: heap-buffer-overflow in __asan_memcpy

A 12-byte write into a 10-byte region. Because the destination is row_buf + 1, the write runs from offset 1 to offset 12 and ASAN flags the first out-of-bounds byte at offset 10 - three bytes past the end. From a 603-byte input. Deterministic across runs.

Linear Scaling - Verified

Three bytes sounds harmless. It isn't. Using a width-tunable APNG generator mirroring the shrink-then-grow pattern, the OOB write size scales linearly with canvas width:

The bytes past the end are exactly new_rowbytes − old_rowbytes, since both allocations carry the same one-byte filter prefix. For RGB8 following a 1-pixel frame that is W × 3 − 3 bytes per row. Multi-row frames re-trigger per row; multi-frame APNGs re-trigger per wide post-narrow frame. At libpng's default user-width limit and 4 bytes per pixel, a single overflowing row writes approximately 4 MB of attacker-controlled bytes past a 4-byte allocation.

Attacker control properties

• Bytes written: 100% attacker-controlled. With filter=None, IDAT/fdAT pixel bytes survive to the memcpy verbatim; other filters are reversible.
• Write size: attacker-tunable from 1 byte to ~4 MB by IHDR width and the fcTL frame-width pattern.
• Determinism: same input ⇒ same OOB size, same memcpy call site, same relative offset. Allocator address differs run to run; the delta is constant.
• Repeatability: an 8-frame seed gives 3+ OOB writes back-to-back. Under the deterministic bump allocator they land on the same reused row_buf slot; against glibc the slot is reused too, so the repetition is depth, not spread. A single sub-1 KiB input file produces multiple OOB hits.

Reachability

Grepping the libpng tree for png_write_frame_head and png_write_frame_tail turns up their definitions and exactly one caller: pngtest.c:1553. Several commonly-tested tools - apngasm, apngopt, and ImageMagick - bypass this API entirely, assembling APNG containers with fwrite directly and did not reproduce the bug. Read-only consumers do not reach the write path. The realistically affected population is any encoder built directly against libpng's per-frame APNG write API.

ASAN reports the existence of the bug. To characterise the primitive it produces, I built a non-ASAN debug build (build-noasan/) and ran a conditional-breakpoint gdb script on libpng's own pngtest binary with the W=64 PoC input. The script breaks only when rowbytes + 1 > chunk_size - i.e. only on actual OOB rows.

Six OOB writes from one input file, all landing at the same row_buf heap slot 0x555555593090 (deterministic per-input). chunk_size = 0x20 (32 B), writable region 24 B, memcpy 192 B - 168 B past the usable region per fire, or 169 counting the filter byte the copy skips. (The scaling table above measures against ASAN's exact-size allocation; glibc rounds the same request up to a 24-byte usable region, so the two figures differ by the rounding, not by disagreement.)

A separate patch-validation harness (apng_write_transform_fuzzer.c) called png_set_filter / png_set_compression_level / png_set_compression_strategy / png_set_compression_buffer_size between every frame head, with values driven by a hash of the input. Its first pass against unpatched libpng18 fired:

A different alloc site - png_set_filter allocates try_row and tst_row at the time it is called, and only when they are NULL - so a stale pair from an earlier frame is kept rather than replaced. Same root cause: per-frame scratch buffer left alive across a frame transition that narrows then widens.

The same disclosed patch (which frees try_row and tst_row in png_write_reset) covers this manifestation too. Second pass against the patched build: 90 minutes, 147.9 M execs, 0 trips. Variant A confirms the patch is correct beyond the specific call sites in the original reproducers. A smaller patch freeing only row_buf would leave this manifestation open.

Why a purpose-built target

A real exploit chain against pngtest would need an info leak (for ASLR bypass) and a heap-shaping primitive (to control allocation adjacency). Both are standard assumptions in modern heap-corruption literature - and orthogonal to whether the OOB primitive is convertible to control-flow. To keep the demo crisp, both assumptions are materialised inside the target binary rather than papered over at runtime:

• Fixed code addresses. Built with -no-pie, so &pwn is a compile-time constant.
• Deterministic heap. glibc's malloc/free/calloc/realloc overridden by a bump allocator backed by mmap(MAP_FIXED, 0x100000000, 16 MiB). Every allocation address is a function of allocation serial number.

The mechanic

The bump allocator detects libpng's narrow-frame malloc(4) (1 px RGB8 + filter byte) and reserves the next 16 bytes for an fp_table struct that lands inside the soon-to-fire OOB write range:

After each frame's encode, vuln_app calls fp_table->cb(). With benign input, cb is &benign. With the exploit input, cb is whatever the OOB just wrote.

The exploit input

gen_exploit_png.py generates a 638-byte 8-frame APNG with widths 64,64,64,32,1,64,64,64 - same shrink-then-grow shape, scaled to W=64. Wide post-narrow frames carry &pwn as little-endian 8 bytes at pixel-row offset 15..22:

The OOB memcpy lands those 8 bytes onto fp_table->cb. The next call site invokes pwn(), which runs system("xcalc") and writes /tmp/PWNED.txt.

Negative test: passing 0xdeadbeef instead of &pwn overwrites the callback with garbage and the call site SIGSEGVs deterministically. That is the negative control proving the overwrite hits the right offset.

Glibc dependence and mitigation envelope

The standard heap-exploitation paths depend on glibc allocator internals that have changed across versions:

• __free_hook / __malloc_hook: removed in glibc 2.34 (2021-08). Pre-2.34 distros (Ubuntu ≤ 20.04, Debian ≤ bullseye, RHEL ≤ 8) remain exposed to the simplest hook-overwrite chain.
• Unsorted-bin FD/BK sanity check: added in glibc 2.32. Defeats the classic unsorted-bin-attack write primitive on ≥2.32. Tcache poisoning still works.
• Tcache safe-linking: also added in glibc 2.32. Defeats naïve tcache poisoning on ≥2.32; attacker-controlled FD must now be XORed with the chunk's location before insertion.

The verified primitive (100% attacker bytes onto adjacent unsorted-bin chunk metadata) is the same primitive real-world CVEs against allocator-adjacent OOBs have exploited. Whether it is RCE-grade on a given target depends on host glibc version, ASLR posture, and heap layout - none of which the bug controls.

Before publishing severity claims I checked which user-space tools actually call libpng's per-frame APNG write API:

Grepping the libpng tree for png_write_frame_head and png_write_frame_tail turns up their definitions in pngwrite.c and exactly one caller, pngtest.c:1553. pngtest is the only caller of the per-frame APNG write API in libpng's own tree. Debian ships it in the libpng-tools package and runs it during make test.

The realistically affected population is narrower than "image CDNs / re-encoders": (1) pngtest itself - shipped binary, runs during build/CI; (2) any encoder built directly against libpng's per-frame APNG write API; (3) future encoders written against this API without awareness of the lifecycle requirement. Read-only consumers - browsers, image viewers, decoders that don't call png_write_* - do not reach the vulnerable path.

Eight validation campaigns across five days answered the obvious follow-up: does the patch close the full family, or only the known reproducers? Cumulative validation fuzz: ~7.7 billion executions across 30+ distinct harnesses, 5 sanitizer combinations, 3 independent comparators (libspng, stb_image, libpng16), and patched + unpatched builds.

The patch-diff sweep is the strongest single piece of evidence: of 7,375 deterministically-classified inputs from every prior corpus, 322 trip the unpatched build (FIXED_FAMILY); 0 trip the patched build. Plus 616 M execs of additional libFuzzer + MSAN pressure on the patched build alone, also 0 trips. The validation campaign found strong evidence that the patch closes the observed finding_002/003 family across every harness shape tested.

For completeness: the same campaign also produced a low-severity write-side hardening item that was filed as a separate report to libpng's public list, not bundled with 002/003.

finding_001 - sub-byte gray pad-bit propagation (CWE-908). png_combine_row (pngrutil.c:3870) preserves the destination row buffer's pre-memcpy padding bits across the memcpy that fills the row. For sub-byte grayscale rows whose (width × bit_depth) mod 8 ≠ 0, those preserved bits are uninitialised and propagate into the IDAT byte stream when the buffer is later written.

PNG 1.2 §7.2 explicitly leaves the value of those padding bits unspecified, so the behaviour is spec-compliant - but it is at odds with the common-practice convention (lodepng, stb_image_write, Wuffs, libspng all zero-pad). The pad-bit issue is structural across the entire libpng 1.6 series; the relevant OR-restore line is byte-for-byte identical between v1.6.43 (pngrutil.c:3679) and HEAD.

An observability study (185×256 1bpp images, allocator-fill 0xAA / 0x55 / 0xCC, 100 trials per arm) bounded the leak window:

• Theoretical per-image leak: 1,792 bits (256 rows × 7 pad bits).
• Actually observable: ~49 / 1,792 (~2.7%). Remaining rows return zero regardless of allocator fill.
• Stddev 0 across trials per arm - deterministic per-input.

49 bits per image is too small to reconstruct a 64-bit pointer reliably, and the leakable bits map to fresh-malloc residue (predominantly zero or low-entropy on most allocators). Treated as hardening, not exploitable info disclosure.

1. Fuzz the write side. OSS-Fuzz historically pressures decode. A natural read-then-re-encode harness - the very thing image-processing pipelines actually do - was enough to surface security-relevant write-side memory corruption in under 30 minutes against a continuously-fuzzed library.
2. Width-varying multi-frame APNG is the structural weak shape. Generators that emit only uniform-width APNGs miss this entire bug class. The shrink-then-grow pattern 4,4,4,3,1,4,4,4 is the canonical worst case.
3. Lifecycle helpers are bug factories. png_write_reset looks like a 3-line helper. It zeroes frame-progress fields and leaves the four scratch buffers alone, trusting the allocation path to sort itself out. It does - for row_buf. What it does not account for is that png_write_filtered_row has already moved the previous frame's buffer into prev_row. The state a lifecycle helper misses is often state that some other function moved. One root cause, three manifestations (finding_002, finding_003, Variant A), one patch.
4. Get the root cause reviewed by someone who owns the code. My reported mechanism was wrong. The reproducers were right, the patch was right, and the severity was right - but the causal story was still wrong, because it was inferred from the allocation path without instrumenting the swap. The maintainer caught it in triage by instrumenting png_write_start_row and finding it fired every frame at the correct size. A mechanism that predicts the observed crash is not the same thing as the mechanism.
5. Linearly-scaling OOBs should not be dismissed by their smallest reproducer. "Three bytes past a ten-byte allocation" sounds harmless. "Up to 4 MB of attacker-controlled bytes onto adjacent heap metadata" doesn't. The correct framing always quantifies the primitive at the user-limit ceiling, not the canonical-seed minimum.
6. Reachability is half the severity story. apngasm, apngopt, and ImageMagick all bypass libpng's per-frame APNG write API by accident - they assemble APNG containers manually with fwrite. The realistically affected population is materially smaller than "image CDNs and server-side optimisers" suggests. This scoping detail matters for any severity assessment.
7. Patch validation matters as much as the initial finding. The same patch closed the original leak, the OOB write, and the later Variant A manifestation - three distinct alloc sites - across billions of follow-up executions. A finding is not finished when the bug fires; it is finished when the patch is verified to close the full family.
8. Saturation is a finding too. Roughly 7.7 billion executions across 30+ harness shapes with zero new disclosure-grade bugs is positive evidence that the patched libpng18 APNG-write surface is tight under all the angles this campaign tried. A future researcher should pivot target rather than re-running the same harnesses.
9. AI-driven fuzzing is good at exhaustion, not insight. The bug fired because one mutation strategy out of fifty perturbed per-frame fcTL widths independently. The agent didn't reason its way to the bug class; it ran the search space hard enough that the structural weak shape surfaced. The methodological claim isn't "agents are smarter"; it's "agents don't get tired, and they don't decide a surface is probably fine."

The confirmed affected set is narrow, and it is worth being precise about that rather than gesturing at libpng's install base. Four gates must all be true before an application is in scope: (1) the linked libpng exposes APNG write support (PNG_WRITE_APNG_SUPPORTED); (2) the application actually writes APNG through the per-frame API, not merely reads or views it; (3) frames of differing widths reach that API; and (4) attacker-influenced input can shape the frame sequence or geometry. Read-only consumers fail gate 2 structurally, which removes browsers, image viewers, and every plain decoder from the picture.

The maintainer's assessment and mine agree: the only in-tree caller of png_write_frame_head / png_write_frame_tail is pngtest.c. The realistically affected population is pngtest - shipped in Debian's libpng-tools - plus any application built directly against libpng's per-frame APNG write API.

Third-party API reachability

One concrete data point that this is not a purely in-tree surface: the Python package imagecodecs calls png_write_frame_head and png_write_frame_tail explicitly from its _apng.pyx Cython extension, against a vendored libpng-apng-patched build. That is source-level evidence of the API being used outside libpng's own tree.

Surveyed tools

What this is not

This is not remotely triggerable against a decoder. Receiving, viewing, or displaying a PNG or APNG does not reach the vulnerable code. Any application is in scope only if it generates APNG through libpng's per-frame write API - so the useful question about any given product is not "does it display PNG?" but "does any part of its pipeline encode APNG through png_write_frame_head?" I have not confirmed that for any consumer product, and I am not going to imply it by listing names.

Version reach

libpng18. libpng17 was abandoned years ago, and libpng16 does not and will not carry APNG. The caveat is the third-party libpng-apng patch: a patched v1.6.x build will most likely carry the identical defect, and those downstreams should pick up the fix once it lands upstream. Mainstream system libpng on Debian, Fedora, and Arch ships the 1.6 stable line without the APNG write API, which bounds today's exposure - but that changes as libpng18 reaches distribution channels, which is the argument for fixing it now rather than later.