[CVE-2026-6100] Possible UAF in {LZMA,BZ2,_Zlib}Decompressor

See CVE-2026-6100 for more information.

Linked PRs

gh-148395: Fix a possible UAF in {LZMA,BZ2,_Zlib}Decompressor #148396
[3.13] gh-148395: Fix a possible UAF in {LZMA,BZ2,_Zlib}Decompressor (GH-148396) #148479
[3.14] gh-148395: Fix a possible UAF in {LZMA,BZ2,_Zlib}Decompressor (GH-148396) #148480
[3.12] gh-148395: Fix a possible UAF in {LZMA,BZ2,_Zlib}Decompressor (GH-148396) #148503
[3.11] gh-148395: Fix a possible UAF in {LZMA,BZ2}Decompressor (GH-148396) #148504
[3.10] gh-148395: Fix a possible UAF in {LZMA,BZ2}Decompressor (GH-148396) #148505
gh-148395: Add regression tests for decompressor UAF after MemoryError (CVE-2026-6100) #154713

[3.10] gh-148395: Fix a possible UAF in `{LZMA,BZ2}Decompressor` (GH-…

[3.11] gh-148395: Fix a possible UAF in `{LZMA,BZ2}Decompressor` (GH-…

Hey guys! I can see that building from source would already include the mitigation.
However, I am not sure about the mechanisms of the python install manager or other installation methods.
https://www.python.org/downloads/release/pymanager-252/

The Python install manager will automatically update within a day of an update being released.

Does that mean we have to wait for 3.14.5 or is a job running nightly, building from source, so the pymanager will distribute the patch already/tomorrow for 3.12?

Hi! You'll have to wait for the 3.14.5 release or the 3.12.14.

Also, note that the 3.12 has not landed yet, it is waiting for the RM.

Hi! You'll have to wait for the 3.14.5 release or the 3.12.14.

Is there a specific release rhythm for patch releases (it seems like it's around once a month) ? I read somewhere that they can be released faster if the issue is critical enough. Is there a chance that this will happen sooner, as this received a CVSS score of 9.1?

See the linked PEP for each version in this table, it lists planned upcoming release dates. There will be no expedited release for this vulnerability.

Hi! You'll have to wait for the 3.14.5 release or the 3.12.14.

Is there a specific release rhythm for patch releases (it seems like it's around once a month) ? I read somewhere that they can be released faster if the issue is critical enough. Is there a chance that this will happen sooner, as this received a CVSS score of 9.1?

It's actually fairly unlikely that the affected implementation is present anywhere, more so that it is present in an environment where the exploitation would benefit the attacker. So I wouldn't worry too much.

Especially as the bug can easily be fixed by adjusting the implementation. So other projects can already just initialise a new instance of decompress() and they won't be affected anymore.

At least that's my understanding from looking into it. Please correct me if I'm wrong.

I've been playing with this issue for a couple of hours now, and I have a question: What's gonna happen, if this memory allocation:

cpython/Modules/_bz2module.c

Lines 493 to 497 in 2a07ff9

    
           tmp = PyMem_Realloc(d->input_buffer, new_size); 
        
           if (tmp == NULL) { 
        
               PyErr_SetNone(PyExc_MemoryError); 
        
               return NULL; 
        
           }

fails? Shouldn't it also lead to the error label or at least clear the bzs->next_in pointer here? I ran into it when I tried to use _testcapi.set_nomemoty with different arguments to hit the issue on different versions of Python where the buffering is implemented with different levels of optimizations.

Shouldn't it also lead to the error label or at least clear the bzs->next_in pointer here?

The current code looks correct to me, but I'm not a bz2 expert.

At least, the following script behaves the same with and without error injection.

import _testcapi
import bz2

INJECT_ERROR = True

data = bz2.compress(b'x' * 1024)
data2 = bz2.compress(b'y' * 1024)
decompressor = bz2.BZ2Decompressor()

res = decompressor.decompress(data, 1)
print("call #1", res)
assert res == b'x'

if INJECT_ERROR:
    try:
        try:
            print("call #2...")
            _testcapi.set_nomemory(0,1)
            decompressor.decompress(data2)
        finally:
            _testcapi.remove_mem_hooks()
    except MemoryError:
        print("*MemoryError*")
    else:
        raise Exception

res = decompressor.decompress(data2)
print("call #3", res)
assert res == b'x' * 1023

By the way, I'm surprised that the argument of the 3rd call (data2) seems to be ignored. But I don't know bz2 API, so I don't know if it's expected or not.

pythongh-148395: Fix a possible UAF in `{LZMA,BZ2,_Zlib}Decompressor` (…

Update python310 to version 3.10.20 / rev 77 via SR 1349663

Update python315 to version 3.15.0~a8 / rev 13 via SR 1349863

Update python313 to version 3.13.13 / rev 41 via SR 1349656

Hi, is there any update on the expected release of 3.12.14?

We have several vulnerability tickets open for this that have been pending for around two months, and we’re currently unable to close them or provide mitigation guidance without the update.

Any visibility on timeline would be greatly appreciated. Thanks.

Python 3.12 releases are provided on an as-needed basis, at the Release Manager's discretion.

You'll have to apply patches for the vulnerabilities you are affected by.

pythongh-148395: Add Tests NEWS entry for decompressor UAF regression…

pythongh-148395: Avoid Sphinx role nits in Tests NEWS entry

[3.12] gh-148395: Fix a possible UAF in `{LZMA,BZ2,_Zlib}Decompressor` (

package/python3: security bump to v3.12.14

[CVE-2026-6100] Fix a possible use-after-free in `{LZMA,BZ2,_Zlib}Dec…

[CVE-2026-6100] Fix a possible use-after-free in `{LZMA,BZ2}Decompres…

[CVE-2026-6100] Fix a possible use-after-free in `{LZMA,BZ2,_Zlib}Dec…

[3.10] pythongh-148395: Fix a possible UAF in `{LZMA,BZ2}Decompressor` (

Navigation Menu

Repository navigation

[CVE-2026-6100] Possible UAF in `{LZMA,BZ2,_Zlib}Decompressor` #148395

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	tmp = PyMem_Realloc(d->input_buffer, new_size);
	if (tmp == NULL) {
	PyErr_SetNone(PyExc_MemoryError);
	return NULL;
	}

[CVE-2026-6100] Possible UAF in {LZMA,BZ2,_Zlib}Decompressor #148395

Description

Linked PRs

Activity

Xentraxx commented on Apr 14, 2026

Eclips4 commented on Apr 14, 2026

StanFromIreland commented on Apr 14, 2026

oscilloscode commented on Apr 16, 2026

StanFromIreland commented on Apr 16, 2026

Xentraxx commented on Apr 16, 2026

frenzymadness commented on Apr 17, 2026

vstinner commented on Apr 17, 2026

geomcegme commented on Jun 12, 2026

StanFromIreland commented on Jun 12, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

[CVE-2026-6100] Possible UAF in `{LZMA,BZ2,_Zlib}Decompressor` #148395