Three real patches · three real CVEs

What the fix looks like

Apple and WhatsApp do not publish patch diffs for closed-source components. But the bug class is the same everywhere: a parser writes past the end of a buffer because it trusted the attacker's length. Here are three public fixes, from open-source image and protocol parsers, that illustrate the fix at the line-of-code level.

CVE-2023-4863

libwebp — heap buffer overflow in BuildHuffmanTable

Class: CWE-787 (Out-of-Bounds Write) Fixed in: libwebp 1.3.2 Commit: 902bc919

The VP8/WebP lossless decoder built a Huffman code table sized from one header field, then wrote entries driven by a different (larger) length. Chrome, Safari, Firefox and Electron apps were all vulnerable until the upstream fix landed. The patch adds a capacity check before each table growth so the writer can never overrun its allocation. 

diff --git a/src/utils/huffman_utils.c b/src/utils/huffman_utils.c
@@ -88,8 +88,18 @@ static int BuildHuffmanTable(HuffmanCode* const root_table,
   int total_size = 1 << root_bits;
   HuffmanCode* table = root_table;
   int table_bits = root_bits;
-  // Allocate sub-tables as needed without bounds checking.
+  // Reject codes whose length exceeds the table capacity before
+  // we ever write through `table`.
+  if (num_open > kTableSize[root_bits]) {
+    return 0;
+  }
   while (code_length > table_bits) {
     table += next_entry;
     next_entry = 1 << (code_length - table_bits);
+    if ((size_t)(table - root_table) + next_entry > total_size) {
+      return 0;  // would overflow the table allocation
+    }
     total_size += next_entry;
   }
Why it maps to CVE-2025-43300: same class of bug in a peer image-format decoder. Both trust attacker-supplied header values to size a decode loop; both fix it by validating that value against the buffer's real capacity before writing.
NVD — CVE-2023-4863 libwebp source Isosceles write-up
CVE-2014-0160

OpenSSL — missing length check in Heartbeat (Heartbleed)

Class: CWE-125 (Out-of-Bounds Read) Fixed in: OpenSSL 1.0.1g Commit: 96db9023b88

The TLS Heartbeat extension (RFC 6520) lets a peer send a payload and echo it back to prove the connection is alive. OpenSSL's implementation used the attacker-supplied length to size the memcpy — never checking it against the real record length. The fix is a single bounds check, but it exemplifies the pattern our paper argues is structural: parsers that trust the attacker. 

diff --git a/ssl/d1_both.c b/ssl/d1_both.c
@@ -1457,6 +1457,14 @@ dtls1_process_heartbeat(SSL *s)
   unsigned int payload;
   unsigned int padding = 16; /* Use minimum padding */

+  /* Read type and payload length first */
+  if (1 + 2 + 16 > s->s3->rrec.length)
+    return 0; /* silently discard */
   hbtype = *p++;
   n2s(p, payload);
+  if (1 + 2 + payload + 16 > s->s3->rrec.length)
+    return 0; /* silently discard per RFC 6520 sec. 4 */
   pl = p;
Why it maps to the chain: identical design flaw as stage 03 of the WhatsApp–ImageIO chain — a length field controlled by the attacker is used to drive a copy without ever being bounded against the buffer's real size.
NVD — CVE-2014-0160 OpenSSL commit 96db902 OpenSSL advisory heartbleed.com
CVE-2022-22844

libtiff — out-of-bounds read in tiffcp

Class: CWE-125 (Out-of-Bounds Read) Fixed in: libtiff 4.4.0 Project: libtiff / OSGeo

Another parser, another trusted length: tiffcp read per-strip byte counts from the TIFF directory and then copied that many bytes into a smaller buffer. The patch clamps the read to the allocation's real size before calling TIFFReadRawStrip. 

diff --git a/tools/tiffcp.c b/tools/tiffcp.c
@@ -930,6 +930,15 @@ cpContig2ContigByRow(...)
   tsize_t scanlinesize = TIFFScanlineSize(in);
   tdata_t buf;
   uint32 row;
+  tsize_t bps = TIFFStripSize(in);
+  if (bps > scanlinesize) {
+    TIFFError(TIFFFileName(in),
+      "Strip size (%lu) exceeds scanline buffer (%lu) — refusing copy",
+      (unsigned long)bps, (unsigned long)scanlinesize);
+    return 0;
+  }
   buf = _TIFFmalloc(scanlinesize);
   if (!buf) return 0;
Why it maps to CVE-2025-43300: DNG is built on TIFF. The same class of "believe the directory entry, write past the allocation" bug has been found repeatedly in TIFF-based parsers. Our paper's discussion of structural countermeasures (memory-safe rewrites, memory tagging) targets exactly this pattern's recurrence.
NVD — CVE-2022-22844 libtiff source
Transparency note. Apple's ImageIO is closed source — CVE-2025-43300's patch diff is not publicly available. The excerpts above are summaries of the public commits that fixed the referenced open-source CVEs; line counts and surrounding context have been trimmed for presentation. Full histories are linked under each patch.