Source linked

PyO3 nth_back Integer Underflow Exposes Arbitrary Memory Reads

github.com@threat_watch1 hour ago·Cybersecurity·3 comments

An integer underflow in PyO3's nth_back iterator methods allows reading arbitrary memory past the end of Python list and tuple storage, affecting all versions 0.24.0 through 0.28.x.

pyo3rustsecmemory safetyinteger overflowout of bounds readpython ffi

A RustSec advisory published June 11, 2026 reveals that PyO3's optimized iterator methods for Python lists and tuples perform unchecked integer arithmetic, enabling out-of-bounds reads that can leak arbitrary memory.

How the Integer Overflow Works

PyO3 0.24.0 introduced custom Iterator::nth and DoubleEndedIterator::nth_back implementations for BoundListIterator and BoundTupleIterator. These compute a target index using index + n — a plain usize addition with no overflow guard. The result is then bounds-checked against the sequence length before an unchecked get_item_unchecked call.

In nth, a large n plus a non-zero internal index can overflow and wrap to a small number, passing the bounds check and reading elements that were already yielded by the iterator. In nth_back, the same underflow pattern allows reads of arbitrary memory past the end of the list or tuple storage. No panic, no courtesy — just a raw pointer dereference into whatever sits next in the Rust heap.

Affected Versions and the Fix

The advisory tags every PyO3 release from 0.24.0 up to (but not including) 0.29.0 as affected. The fix landed in version 0.29.0 — no point releases in between. The four vulnerable functions are listed explicitly: pyo3::types::list::BoundListIterator::nth, BoundListIterator::nth_back, pyo3::types::tuple::BoundTupleIterator::nth, and BoundTupleIterator::nth_back. All four share the same root cause: arithmetic on usize without wrapping or saturating semantics.

Why This Matters for Rust-Python FFI

PyO3 is the de facto bridge for writing Python extensions in Rust. When you call .nth() on a PyList iterator from Rust, you're trusting that the compiler's zero-cost abstractions don't hide a memory-safety hole. This bug proves that assumption wrong — an attacker who controls n (or can influence iterator state) can read data that Rust's type system is supposed to protect.

If you're running PyO3 between 0.24.0 and 0.28.x, upgrade to 0.29.0 now — the alternative is a Rust iterator that can read past your tuple's storage as if it were a pointer buffet.


Source: report memory exposure in PyO3 nth_back iterator methods
Domain: github.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.