Report memory exposure in PyO3 nth_back iterator methods

crates/pyo3/RUSTSEC-0000-0000.md

@@ -0,0 +1,36 @@
+```toml
+[advisory]
+id = "RUSTSEC-0000-0000"
+package = "pyo3"
+date = "2026-06-11"
+url = "https://github.com/PyO3/pyo3/pull/6086"
+categories = ["memory-exposure"]
+keywords = ["out-of-bounds-read", "integer-overflow"]
+
+[affected.functions]
+"pyo3::types::list::BoundListIterator::nth" = [">= 0.24.0"]
+"pyo3::types::list::BoundListIterator::nth_back" = [">= 0.24.0"]
+"pyo3::types::tuple::BoundTupleIterator::nth" = [">= 0.24.0"]
+"pyo3::types::tuple::BoundTupleIterator::nth_back" = [">= 0.24.0"]
+
+[versions]
+patched = [">= 0.29.0"]
+unaffected = ["< 0.24.0"]
+```
+
+# Out-of-bounds read in `nth` / `nth_back` for `PyList` and `PyTuple` iterators
+
+PyO3 0.24.0 added optimized implementations of `Iterator::nth` and
+`DoubleEndedIterator::nth_back` for the `BoundListIterator` and
+`BoundTupleIterator` types. These implementations computed the target index
+using unchecked `usize` addition (`index + n`) before bounds-checking against
+the sequence length, then read the element via `get_item_unchecked`.
+
+In `nth` methods, a sufficiently large `n` (combined with a non-zero internal
+index) could cause the addition to overflow and wrap around, producing a small
+"target index" that passed the bounds check and enabling reads at the front
+of the `list` or `tuple` of elements previously yielded by the iterator.
+
+In `nth_back` methods, a sufficiently large `n` could cause underflow in a
+similar fashion, however would instead allow reads of arbitrary memory past
+the end of the `list` or `tuple` storage.