fix bugs with list / tuple iterator "nth" operations#6086
Conversation
|
I think this out-of-bounds read is worth filing to the RustSec advisory db. Unlike the other discoveries from Codex that we've handled as part of #6010, I think this one could easily manifest as a vulnerability in user code which could lie undetected until a malicious attacker passes a large N. Reviewers, please let me know if you agree with me! |
ngoldbaum
left a comment
ngoldbaum
left a comment
There was a problem hiding this comment.
Overall looks good and probably fine to merge as-is but I spotted some issues.
| @@ -0,0 +1,2 @@ | |||
| - Fix possible out of bounds read in `BoundListIterator` and `BoundTupleIterator`'s `nth` and `nth_back` implementations. | |||
There was a problem hiding this comment.
Isn't only nth_back a possible UB?
There was a problem hiding this comment.
nth when the iterator has been advanced forwards could still wrap around to the front of the collection. This isn't UB in the same way as the read of undefined mem in nth_back, but still a bug.
Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
) (#115) Two RUSTSEC advisories published 2026-06-11 against pyo3 0.28.x, both fixed in 0.29.0: - RUSTSEC-2026-0176 — out-of-bounds read (memory exposure) in BoundListIterator/BoundTupleIterator nth/nth_back (PyO3/pyo3#6086) - RUSTSEC-2026-0177 — missing Sync bound on PyCFunction::new_closure closures (PyO3/pyo3#6096) mkui-py calls none of the affected APIs, so this is a pure dependency bump with no source changes. Version lives in [workspace.dependencies]; mkui-py consumes it via { workspace = true }. Verified locally: - cargo deny check advisories — ok (both IDs resolved) - cargo audit — no vulnerabilities - cargo test -p mkui-py --no-default-features --features parity-test,console — pass - cargo fmt/clippy/test/doc/release — all green - no new transitive deps, no MSRV change (0.29 needs 1.63; workspace is 1.87) Closes #114 Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2 participants
This PR fixes issues with
tupleandlistiterators:nth/nth_backwith large N could overflow usize and wrap, leading to out of bounds reads viaget_uncheckednth/nth_backshould exhaust the iterator - the existing implementations did not do thisThis is primarily done by rewriting
nth/nth_backto usechecked_mathematical operations to avoid the possible overflow.I verified the
advance_by/advance_back_bynightly operations were not affected by the same issue; they turned out to be fine, however I wrote them to usesaturating_operations to make it easier (for me) to read their implementations.(Credit to Codex security scanning for the discovery of the out of bound reads; the failure to exhaust is my addition when scrutinising these methods.)