PyString::from_object took &str arguments and forwarded them directly to the Python C API without checking for terminating nul bytes. This could lead the Python interpreter to read beyond the end of the &str data and potentially leak contents of the out-of-bounds read (by raising a Python exception containing a copy of the data including the overflow). In PyO3 0.24.1 this function will now allocate a CString to guarantee a terminating …
In PyO3 0.23.0 the PYO3_CONFIG_FILE environment variable used to configure builds regressed such that changing the environment variable would no longer trigger PyO3 to reconfigure and recompile. In combination with workflows using tools such as maturin to build for multiple versions in a single build, this leads to Python wheels being compiled against the wrong Python API version. All users who distribute artefacts for multiple Python versions are encouraged to …
The family of functions to read "borrowed" values from Python weak references were fundamentally unsound, because the weak reference does itself not have ownership of the value. At any point the last strong reference could be cleared and the borrowed value would become dangling. In PyO3 0.22.4 these functions have all been deprecated and patched to leak a strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.
The family of functions to read "borrowed" values from Python weak references were fundamentally unsound, because the weak reference does itself not have ownership of the value. At any point the last strong reference could be cleared and the borrowed value would become dangling. In PyO3 0.22.4 these functions have all been deprecated and patched to leak a strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.
An issue was discovered in the pyo3 crate before 0.12.4 for Rust. There is a reference-counting error and use-after-free in From<Py>.