PatchHawk looks for security fixes in software updates. For selected cases, we share the code change and steps to reproduce the bug: github.com/78ResearchLab/Pat… Follow @patchhawk_ for more fixes explained through code. #PatchHawk #78ResearchLab

Firefox 151.0.3 includes Mozilla's fix. On Linux, Firefox uses the system FreeType library, so updating Firefox doesn't update that library. PatchHawk compared the releases. We matched the change to this CVE and ran the Docker test ourselves. mozilla.org/en-US/security/a…

FreeType later changed SHZ, the instruction that moves points in a glyph. It now picks the right set of points and stops at the end of that set. The two cards show the code. This fix came after 2.14.3. github.com/freetype/freetype…

In Docker, we used a small program to load Mozilla's font through FreeType's public FT_Load_Glyph API. ASan found no issue with 2.14.2, but caught a read past the end of a buffer in 2.14.3. Mozilla also reported a write past a buffer. bugzilla.mozilla.org/show_bu…

The change is easy to miss. In 2.14.2, FreeType made room for the glyph's existing points, plus four more. In 2.14.3, it only made room for four. That wasn't enough for some glyphs made from other glyphs. github.com/freetype/freetype…

FreeType 2.14.3 introduced a font rendering bug (CVE-2026-10701). Mozilla reproduced a Firefox crash on Linux by loading a specially made font with medium or full hinting enabled. The bug starts with a check that reserves too little memory.

PatchHawk finds security-relevant fixes in release diffs. Selected PoCs include write-ups, repro steps, and pre/post comparisons: github.com/78ResearchLab/Pat… Follow @patchhawk_ for more fixes explained with real code and verifiable PoCs. #PatchHawk #78ResearchLab

The PoC is now public: github.com/78ResearchLab/Pat… It includes the 345-byte JXL input, Docker reproduction scripts, 0.11.1/0.11.2 djxl logs, and the Valgrind trace. The README states the tested 32-bit scope and limitations.

Upstream named the fix in v0.11.2: github.com/libjxl/libjxl/rel… Patch: github.com/libjxl/libjxl/pul… PatchHawk flagged the arithmetic change; its PoC attempt was incomplete, so we verified the CLI and Valgrind results manually.

The native 32-bit CLI exited 139 on 0.11.1. Version 0.11.2 returned a frame-creation error for the same file; a 256×256 control decoded on both. We did not establish code execution or a downstream network path.

Before the fix, PackedImage::Create() allocated after unchecked size arithmetic. The decoder’s output callback then wrote beyond that buffer. The patch calls VerifyDimensions() first and rejects wrapped stride or total size. The card shows the actual code change.

The JXL file holds an 8×8 cropped frame on a 32,768×10,923 canvas. djxl --disable_output still decodes to float RGB pixels. Packed storage would need 4,295,098,368 bytes (2³² + 131,072), which wraps in 32-bit size_t.

libjxl 0.11.2 checks packed-image size before allocation. In our native 32-bit djxl test, a 345-byte JXL file crashed 0.11.1; Valgrind recorded invalid 4-byte writes. 0.11.2 rejects the same file.

PatchHawk finds security-relevant fixes in release diffs. Selected PoCs include write-ups, repro steps, and pre/post comparisons: github.com/78ResearchLab/Pat… Follow @patchhawk_ for more fixes explained with real code and verifiable PoCs. #PatchHawk #78ResearchLab

Both reproductions use FFmpeg's CLI entry points and are packaged in Docker. They show sanitizer-detected writes; we did not demonstrate code execution or an unsanitized crash. Ogg PoC: github.com/78ResearchLab/Pat… Filter PoC: github.com/78ResearchLab/Pat…

That leftover multiplication matters. delay=12180 passes the new 9.0.2 check. In our x86-64 sanitizer build, it overflows and ASan catches a 4-byte heap write just before analysis_buf. The same input faults on 9.0.1. For this build, the 9.0.2 check is incomplete.

Now the filter. On 9.0.1, firequalizer=delay=30000 overflows the FIR-length calculation under UBSan. 9.0.2 rejects that value. But a later signed multiplication, nsamples_max * 2, is still there. Patch: github.com/FFmpeg/FFmpeg/com…

There's a catch to that Ogg result: FFmpeg's default allocation limit rejects the >4 GB file on both versions. We had to raise -max_alloc to 8 GiB to reach the 9.0.1 fault. The file is sparse, but parsing it still takes real memory and time.

In the Ogg demuxer, buf_realloc() doubled an unsigned buffer size without checking the limit first. Near UINT_MAX/2, that can wrap. On 9.0.1, our raised-limit run hit an ASan invalid write (WRITE of size 31895). On 9.0.2, it returns ENOMEM. Patch: github.com/FFmpeg/FFmpeg/com…

These are two separate paths through FFmpeg. ffprobe parses a continued Ogg packet; ffmpeg takes the firequalizer delay from the command line. We built both 9.0.1 and 9.0.2 from official source in Docker and ran each input against both.