Firefox now ships with a Rust implementation of zlib for gzip compression and decompression. The switch, finalized in version 151, marks a notable shift for one of the web’s most widely used browsers. It brings memory safety guarantees without sacrificing speed. And the latest update to the underlying library addresses a stubborn hardware bug that had plagued users of certain Intel processors for months.
Released on June 21, 2026, zlib-rs 0.6.4 incorporates a workaround for an Intel Raptor Lake stability problem first uncovered during Mozilla’s integration efforts. The bug, tied to a specific MOVB instruction pattern, could trigger silent memory corruption on 13th and 14th generation Intel CPUs. Phoronix first reported the release details, noting the fix arrives alongside SIMD optimizations and other platform improvements.
The issue surfaced in late 2024 as Mozilla engineers worked to replace the system’s zlib with the Rust version. Crashes appeared in Bugzilla reports. Bounds checks failed in ways that should have been impossible. Patterns only emerged after enough user reports accumulated. Fabian Giesen’s analysis of a related Intel erratum helped pinpoint the culprit in Huffman coding routines that write distance-length pairs to memory.
“The toughest bug we’ve encountered so far,” wrote Folkert de Vries of the Trifecta Tech Foundation in a detailed account of the Firefox integration. The foundation stewards the zlib-rs project. Their blog post on the Firefox adoption recounts how the team spent months debugging crashes that resisted local reproduction. The solution? A small, targeted unsafe block that performs an unaligned write to avoid the problematic instruction sequence.
Here is the fixed push_dist function now upstreamed to the library:
pub fn push_dist(&mut self, dist: u16, len: u8) {
let buf = &mut self.buf.as_mut_slice()[self.filled..][..3];
let bytes = dist.to_le_bytes();
unsafe { buf.as_mut_ptr().cast::<[u8; 2]>().write_unaligned(bytes) }
buf[2] = len;
self.filled += 3;
}
Simple. Direct. Effective. Newer versions of LLVM and Clang also sidestep the instruction, providing an independent compiler-level mitigation. Mozilla shipped its patch in May 2025, ahead of broader stabilization. The library update in 0.6.4 makes the fix available to all downstream users.
But the Raptor Lake saga represents only one chapter in zlib-rs’s rapid maturation. The project began as an effort to bring memory safety to one of computing’s most ubiquitous libraries. Zlib powers PNG images, gzip files, HTTP compression, and countless embedded applications. Its original C implementation dates back decades. Buffer overflows and memory management bugs have surfaced over the years. Rust’s ownership model promised a cleaner path forward.
Early versions lagged behind hand-tuned C code in raw speed. Then came a string of performance breakthroughs. By version 0.4.2 in early 2025, the Trifecta team could claim leadership in decompression. Their benchmarks showed zlib-rs outperforming zlib-ng by well over 10% on 1KB chunks and beating Chromium’s specialized zlib on streaming workloads. A clever LLVM compiler flag, -Cllvm-args=-enable-dfa-jump-thread, recovered additional performance in the decompression hot path by improving jump threading for the deterministic finite automata at the heart of inflate.
Those gains carried forward. The 0.6 series stabilized the API, achieved over 30 million crate downloads, and added a production-ready C-compatible interface. Firefox’s adoption provided the ultimate validation. Benchmarks run during integration revealed striking speedups. Decompression of 1KB data at low compression levels ran 5.66 times faster than CPython’s stock zlib on Linux x86_64. Larger 64KB buffers showed gains up to 32.5 times in some configurations. Compression also improved, though differences in output size from algorithm variations complicated direct apples-to-apples comparisons.
Results on Apple silicon proved more modest. macOS ships a heavily optimized zlib with inline assembly. The Rust version initially missed some vectorization opportunities on AArch64. Developers have since identified and begun integrating those improvements. Arm platforms continue to receive attention. The 0.6.4 release fixes an off-by-one error in the AArch64 NEON implementation of Adler32 that produced incorrect checksums under certain integer overflow conditions. Scalar and x86 paths remained unaffected.
Hardware support broadens with each release. Version 0.6.4 adds an optimized CRC32 routine for LoongArch64. It applies a VNNI instruction-level parallelism trick to standard AVX-512 code that yields modest gains on AMD Zen 5 processors. Tests now run conditionally only on systems with AVX-512 support. Miri, Rust’s undefined behavior detector, now validates more SIMD paths, including the new CRC32 implementation. Continuous integration covers powerpc64le and big-endian AArch64 variants.
Contributors from across the Rust community drove these changes. Mike Hommey, known as glandium in open source circles, authored the Raptor Lake workaround. Shenxiul fixed the Adler32 logic. Gelbpunkt delivered the LoongArch CRC32 code. Folkert de Vries, the project’s primary maintainer, authored or reviewed the majority of patches. The release notes credit 17 distinct pull requests that touch everything from aliasing bug fixes in infback to clearer documentation of window_bits behavior.
Performance remains competitive with zlib-ng, the long-time leader among C implementations. On many workloads zlib-rs now matches or exceeds it while offering stronger safety guarantees. The project provides both a pure Rust crate for Rust applications and a drop-in libz.so replacement that can accelerate existing C and C++ code. Projects like flate2 and rustls already depend on the lower-level zlib-rs crate.
Firefox’s move carries particular weight. The browser processes enormous volumes of compressed data daily. Every decompression runs millions of times per user session. Safety matters when handling untrusted web content. Speed matters for perceived performance. The combination proved compelling enough for Mozilla to invest two years in the transition, updating tests for slightly different compressed output and handling symbol prefixing to avoid conflicts with system libraries.
Other distributions and projects watch closely. Fedora already ships zlib-ng. Some developers maintain personal PPAs with accelerated zlib variants. Ubuntu has yet to make a default switch. The emergence of a memory-safe alternative that also delivers top-tier performance could accelerate adoption across Linux distributions and cloud infrastructure.
The Trifecta Tech Foundation positions zlib-rs as a model for rewriting critical systems components in Rust. Their earlier blog posts documented the journey from initial performance parity to outright leadership in decompression. A public benchmark dashboard tracks progress against zlib-ng, stock zlib, and Chromium’s fork over time. Regressions become visible immediately. Optimizations receive clear validation.
Smaller fixes in 0.6.4 address edge cases that matter in production. The library now returns NULL on excessively large allocation requests instead of attempting them. Input validation in inflateBackInit_ prevents certain misuse. An internal API out-of-bounds read was eliminated. These changes reduce the attack surface even further.
Yet challenges remain. Some platforms still trail in vectorization quality. Compiler flags that unlock peak performance require manual specification in certain build environments. The unsafe code required for the Raptor Lake workaround, though minimal and carefully reviewed, highlights that complete elimination of unsafe remains difficult when matching hardware quirks or legacy APIs.
Even so, the trajectory looks clear. A library once considered a straightforward port now drives meaningful advances in both safety and speed. Firefox users gain faster page loads and fewer mysterious crashes on Intel hardware. Downstream Rust projects inherit a more reliable compression primitive. The broader open source community benefits from another high-profile demonstration that Rust can replace battle-tested C code without compromise.
Version 0.6.4 represents steady, focused progress rather than a flashy overhaul. The release notes read like a checklist of practical engineering: fix the CPU bug, correct the checksum calculation, speed up AVX-512 on Zen 5, expand platform testing, tighten CI. Each item matters. Together they make the library more reliable across the diverse hardware that runs modern software.
Developers who integrate zlib-rs today inherit years of accumulated optimizations, hardware-specific workarounds, and rigorous testing. The API has stabilized. The performance sits at or near the top of available options. And the memory safety comes built in. For an infrastructure component as fundamental as compression, those attributes matter a great deal.
WebProNews is an iEntry Publication