Skip to content

gzip._GzipReader.read() with sometimes uninitialized variable #137571

Description

@maurycy

Bug report

Bug description:

This one is easy to spot but hard to reproduce:

if buf == b"":

buf is initialized only when self._decompressor.needs_input:

buf = self._fp.read(READ_BUFFER_SIZE)

It exists since gh-95534 (#97664).

I spent a lot of time trying to reproduce this bug using the standard zlib decompressor without any success:

import gzip
import io

class EvilDecomp:
    def __init__(self, **kwargs):
        self.needs_input = False
        self.unused_data = b""
        self.eof = False
    def decompress(self, data, max_length):
        self.needs_input = True
        return b""

gzip.zlib._ZlibDecompressor = EvilDecomp

with gzip.GzipFile(
    fileobj=io.BytesIO(gzip.compress(b"hello world")), mode="rb"
) as f:
    f.read(1)

results in:

22:16:40.678647000PM CEST maurycy@gimel /Users/maurycy/src/cpython % ./python.exe meow.py
Traceback (most recent call last):
  File "/Users/maurycy/src/cpython/meow.py", line 18, in <module>
    f.read(1)
    ~~~~~~^^^
  File "/Users/maurycy/src/cpython/Lib/gzip.py", line 349, in read
    return self._buffer.read(size)
           ~~~~~~~~~~~~~~~~~^^^^^^
  File "/Users/maurycy/src/cpython/Lib/compression/_common/_streams.py", line 68, in readinto
    data = self.read(len(byte_view))
  File "/Users/maurycy/src/cpython/Lib/gzip.py", line 589, in read
    if buf == b"":
       ^^^
UnboundLocalError: cannot access local variable 'buf' where it is not associated with a value

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Aug 8, 2025
  2. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Aug 8, 2025
  3. ZeroIntensity commented on Aug 9, 2025

    @ZeroIntensity
    Member

    Just for clarification, does this cause an actual problem in practice? The fix seems simple enough that it's probably worth doing, but I want to make sure this isn't just from fuzzing the private API.

  4. maurycy commented on Aug 9, 2025

    @maurycy
    ContributorAuthor

    @ZeroIntensity Nope! Neither. I was reviewing various modules to see how similar are different stream implementations across the stdlib. Many classes provide streaming. They employ different strategies (some copy, some use memoryview etc.) but overlap, and I was curious if there's any opportunity to contribute. That's how I found gh-137524 also.

  5. added a commit that references this issue on May 22, 2026
  6. serhiy-storchaka commented on May 22, 2026

    @serhiy-storchaka
    Member

    Thank you for your report @maurycy.

  7. added
    3.13only security fixes
    3.14bugs and security fixes
    3.15bugs and security fixes
    3.16new features, bugs and security fixes
    on May 22, 2026
  8. added 3 commits that reference this issue on May 22, 2026
  9. added 2 commits that reference this issue on May 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.13only security fixes3.14bugs and security fixes3.15bugs and security fixes3.16new features, bugs and security fixesstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions