Code generated by flatbuffers' compiler is unsafe but not marked as such. See https://github.com/google/flatbuffers/issues/6627 for details.

For example, if generated code is used to decode malformed or untrusted input, undefined behavior (and thus security vulnerabilities) is possible even without the use of the unsafe keyword, violating the the meaning of "safe" code;

All users that use generated code by flatbuffers compiler are recommended to:

1. not expose flatbuffer generated code as part of their public APIs
2. audit their code and look for any usage of follow, push, or any method that uses them (e.g. self_follow).
3. Carefully go through the crates' documentation to understand which "safe" APIs are not intended to be used.

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 nul bytes. PyO3 0.25 will likely offer an alternative API which takes &CStr arguments.

PyCFunction::new_closure (and the temporary new_closure_bound complement in the 0.21–0.22 series) required the supplied closure to be Send + 'static but not Sync. The resulting PyCFunction is a Python callable that can be invoked from any Python thread, which means the closure may be called concurrently from multiple threads, and needs a Sync bound to prevent possible data races.

The problem exists under all Python versions but is particularly vulnerable under the newer free-threaded Python variant, which do not have serial execution imposed by the Global Interpreter Lock. Under releases protected by the GIL, the ability to "detach" from the Python interpreter temporarily inside the closure (e.g. by Python::detach) makes it possible for interleaved and/or concurrent execution of various portions of the closure.

PyO3 0.29.0 added a Sync bound to close this thread-safety bug.