CVSROOT: /cvs
Module name: src
Changes by: [email protected] 2026/11/10 15:07:15
Modified files:
lib/libz : Tag: OPENBSD_7_9 deflate.c gzlib.c gzwrite.c
infback.c inflate.c
Log message:
zlib: fix buffer overwrite in non-blocking gzwrite
Upstream commit df84af25
from tb@
Backport security fixes from zlib 1.4
>From the 9 security fixes listed in
https://github.com/madler/zlib/releases/tag/v1.4
we already have the fix for CVE-2026-85091 in 8.0.
The remaining 8 of these are cherry-picked here for userland, 6 of which
also affect the kernel. That required a bit of fiddling due to our patches
(#ifdef SMALL, size for ZFREE in the kernel).
There is an oob write of 32k and various other oob accesses, some info
leaks and a cloexec carelessness.
from tb@; looks good to deraadt@
In detail this is:
deflate.c, hunks 1 and 2:
commit 1e4178b27f458904d3d2e2256a831708912e8b1a
Author: Jason Gross <[email protected]>
Date: Mon Nov 2 20:43:28 2026 +0000
Fix deflateResetKeep() when used in the middle of a stream.
deflateResetKeep() kept too much, which could result in later reads
outside of the window and invalid deflate streams.
deflate.c, hunk 3:
commit 12d7b90980910fcd7713e58cedcca046acb5a55f
Author: [email protected] <[email protected]>
Date: Fri Jun 5 19:10:15 2026 +0000
Check deflatePrime pending capacity.
Repeated calls of deflatePrime() with no intervening deflate()
could write past the end of pending_buf. Check the bytes that will
be written against the space remaining, moving pending output as
needed.
Reported by Trail of Bits (TOB-ZLIB-013).
gzlib.c (not in kernel):
commit 2ec717a141cbf9091e1d914c15e30278efed5127
Author: [email protected] <[email protected]>
Date: Fri Jun 5 19:10:15 2026 +0000
Fix gzdopen close-on-exec to use the correct flag.
Reported by Trail of Bits (TOB-ZLIB-008).
gzwrite.c (not in kernel):
commit e9415f70eb6a37c4b6b9685b12e8e6ac91c80f54
Author: Mark Adler <[email protected]>
Date: Sun Oct 25 18:29:35 2026 -0700
Avoid writing uninitialized data on a gzip zero fill.
Before, data could be compressed and written to the output from an
uninitialized allocation of memory, possibly exposing internal
data from the application. This would only occur if gzseek() was
used to skip forward before any data had been written, and the next
operation was gzputc(), gzflush(), gzsetparams(), or gzclose().
Now zeros are written.
infback.c:
commit 09a1572aa624e5ddb6c075dc013880de70b1b9b9
Author: Mark Adler <[email protected]>
Date: Sat Feb 21 23:03:37 2026 -0800
Fix inflateBack() bug that would fail to detect a too far back.
The bug would pass off an invalid deflate stream as good, and copy
uninitialized memory contents to the output.
inflate.c, hunk 1:
commit 2fd31f00740ea183b640f3f5c12659420e189c76
Author: Jason Gross <[email protected]>
Date: Mon Nov 2 17:08:31 2026 -0800
Avoid a possible out-of-bounds write after inflateReset().
If inflate() was asked to get the window size from the zlib header,
and that size was invalid, inflateReset() or inflateSync() would
retain it, and a subsequent inflateGetDictionary() could write past
a user-supplied 32K buffer.
Reported by Theorem (THM-ZLIB-001).
inflate.c, hunk 2:
commit e7bb9788e0f0e9252de04fc52c3ada4ddede2f7d
Author: [email protected] <[email protected]>
Date: Fri Jun 5 19:10:15 2026 +0000
Keep primed inflate streams off of the fast path.
After inflatePrime(), inflate() could use inflate_fast() with more
bits buffered than it allows. That could leave next_in pointing
before the start of the input buffer, so that the next inflate()
call would read out of bounds. Use the slow path until fewer than
eight bits remain.
Reported by Trail of Bits (TOB-ZLIB-014).
inflate.c, hunk 3:
commit 8179479c6274c0041189882b8746a33e2376eaf0
Author: Mark Adler <[email protected]>
Date: Mon Oct 26 14:14:33 2026 -0700
Use the maximum window size after inflateSync() if not yet known.
With windowBits 0, inflate() learns the window size from the zlib
or gzip header. If inflateSync() recovered before any header was
processed, decoding continued with a window size of zero, which
allocated a one-byte window. Back-references longer than the output
buffer then failed with "invalid distance too far back", and if the
stream was reused, a header that set the window size would make
updatewindow() write past that one-byte allocation.
Reported by Trail of Bits (TOB-ZLIB-004).
this is errata/7.9/046_zlib.patch.sig
