Description

msmeissn

opened on Apr 28, 2026

Issue body actions

Bug report

Bug description:

(This was found by Gemini, orchestrated by Dirk Mueller at SUSE)

For GHSA-pg25-7cx5-cvcm the "next_in" pointers were reset to NULL. However if the decompressor is reused, the "avail_in_real" counter should also be reset to "0" at this time, as if its reused again, next_in and avail_in_real might not be in sync again.

This affects

Modules/_bz2module.c
Modules/_lzmamodule.c
Modules/zlibmodule.c

For bz2, everywhere where next_in is set to NULL, avail_in_real also needs to be set to 0.

++ bzs->next_in = NULL;
should also set
bzs->avail_in_real = 0;

similar for the others.

This is largely hardening. It is not clear if these use cases exist.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Activity

1. msmeissn

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Apr 28, 2026
2. StanFromIreland

   changed the title [-]additional hardening for CVE-2026-6100[/-] [+]Keep next_in and avail_in in sync in bz2/lzma/zlib decompressor reset paths[/+] on Apr 28, 2026
3. StanFromIreland

   added

   extension-modulesC modules in the Modules dirC modules in the Modules dir

   type-refactorCode refactoring (with no changes in behavior)Code refactoring (with no changes in behavior)

   and removed

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Apr 28, 2026
4. StanFromIreland

   added this to Compression issues 🗜on Apr 28, 2026
5. StanFromIreland commented on Apr 28, 2026

   

   StanFromIreland

   on Apr 28, 2026

   Member

   More actions

   Please note that there is no bug currently, as we use it only if bzs->next_in != NULL (which we do clear). It is up to the compression module maintainers if they want to accept such a hardening.

Issue actions