Python 2.7 readahead is not thread safe


This resource is maintained for historical reference and does not contain the latest vulnerability info for Python.

The canonical database for vulnerabilities affecting Python is available on GitHub in the Open Source Vulnerability (OSV) format. This vulnerability can be viewed online at the Open Source Vulnerability Database.

Reading from the same file object in different threads does crash Python 2.7. The readahead feature of Objects/fileobject.c is not thread safe.

The PSRT decided that it’s a regular bug and doesn’t need to be categorized as a vulnerability, since the attacker has to be able to run arbitrary code in practice.

The PSRT considers that no Python 2.7 application currently rely on reading from the same file object “at the same time” from different thread, since it currently crashs.


  • Disclosure date: 2017-09-20 (Python issue bpo-31530 reported)
  • Reported by: email to PSRT

Fixed In

Python issue

CVE-2018-1000030: Python 2.7 readahead feature of file objects is not thread safe.

  • Python issue: bpo-31530
  • Creation date: 2017-09-20
  • Reporter: STINNER Victor


Python 2.7.14 is vulnerable to a Heap-Buffer-Overflow as well as a Heap-Use-After-Free. Python versions prior to 2.7.14 may also be vulnerable and it appears that Python 2.7.17 and prior may also be vulnerable however this has not been confirmed. The vulnerability lies when multiply threads are handling large amounts of data. In both cases there is essentially a race condition that occurs. For the Heap-Buffer-Overflow, Thread 2 is creating the size for a buffer, but Thread1 is already writing to the buffer without knowing how much to write. So when a large amount of data is being processed, it is very easy to cause memory corruption using a Heap-Buffer-Overflow. As for the Use-After-Free, Thread3->Malloc->Thread1->Free’s->Thread2-Re-uses-Free’d Memory. The PSRT has stated that this is not a security vulnerability due to the fact that the attacker must be able to run code, however in some situations, such as function as a service, this vulnerability can potentially be used by an attacker to violate a trust boundary, as such the DWF feels this issue deserves a CVE.


Timeline using the disclosure date 2017-09-20 as reference: