gh-148286: Fix undefined behaviour in io.StringIO.read() after an overseek

[matthiasgoergens]

_io_StringIO_read_impl() clamps the read size to zero when the position is past the end of the buffer, but still forms the pointer self->buf + self->pos before returning. Nothing is read through it, but forming it is undefined behaviour on its own, and since self->buf is a Py_UCS4 * the byte offset is self->pos * 4 — so for self->pos == 2**62 - 1 the multiplication wraps and yields a pointer four bytes below self->buf.

io.StringIO("abc").seek(2**62 - 1)   # then .read()

stringio.c:352: addition of unsigned offset to 0x... overflowed to 0x...

_stringio_readline() already guards exactly this condition a few lines below, with the comment "In case of overseek, return the empty string", so this applies the same guard on the read path. self->pos += size is a no-op here because size is zero, and ENSURE_REALIZED() is deliberately left ahead of the guard so the state transition and its error path are unchanged.

The existing test_io suite already covers this path — that is how UBSan found it — so no new test is needed. With the Modules/_io/stringio.c entry removed from Tools/ubsan/suppressions.txt, test_io passes under UBSAN_OPTIONS=halt_on_error=1, where before it aborts at stringio.c:352.

• Issue: Various UB warnings found by UBSan #148286

[StanFromIreland]

Same idea as with the ctypes PR, avoid implementation/infra details.

[picnixz]

Please add a regression test.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[matthiasgoergens]

Thanks both.

Regression test — added in 0d659fa, as test_overseek_far_past_end.

One thing worth being explicit about, because it affects how much the
test is worth: it passes on unfixed builds too. I checked before
writing it — io.StringIO and _pyio.StringIO, and BytesIO for both,
already return '' with the correct tell() and getvalue() at every
offset it tries. The bug is undefined behaviour, and UB is not generally
observable; a normal build gives no signal here.

So the test pins the documented behaviour rather than detecting the
defect. It is still worth having: the existing test_overseek only
seeks one past the end, so nothing covered the large-offset case at all,
and that is precisely where the arithmetic wraps — the pointer overflow
only occurs above PY_SSIZE_T_MAX // 4. It is in MemoryTestMixin, so
it runs for BytesIO as well as StringIO, C and pure-Python.

What actually guards the fix is the other half of the diff: removing

pointer-overflow:Modules/_io/stringio.c

from Tools/ubsan/suppressions.txt, which .github/workflows/reusable-san.yml
consumes. With the suppression gone, the UBSan job fails if the UB comes
back. That is the regression guard; the unit test is the behavioural
one. Happy to add more of the latter if you would like, but I did not
want to imply it catches what it does not.

NEWS entry — trimmed to the user-visible statement, no macro names,
no description of the fix, no suppressions note.

I have made the requested changes; please review again

[bedevere-app]

Thanks for making the requested changes!

@picnixz: please review the changes made to this pull request.

[matthiasgoergens]

Correction to my last comment, and a retraction: the test I added was
redundant and I have removed it (9d3ba83).

I said the suppression removal was the regression guard and the unit
test the behavioural one. The first half is right; the second oversold
it. CStringIOTest.testSeek already covers this — it has all along:

self.assertEqual(sys.maxsize, bytesIo.seek(sys.maxsize))
self.assertEqual(self.EOF, bytesIo.read(4))

That is exactly the case where the arithmetic wraps, and it is what
produced the diagnostic recorded in Tools/ubsan/suppressions.txt.

Verified rather than argued, building with CI's own configuration
(--with-undefined-behavior-sanitizer --with-strict-overflow, clang 22):

	UBSan report
unfixed, testSeek	fires — addition of unsigned offset to 0x…a60 overflowed to 0x…a5c
unfixed, overseek by 11 / 100 / 2³¹	none
unfixed, offsets ≥ 2⁶²−1	fires
fixed, full test_io	none; all 9 tests OK

So small overseeks produce no report at all, which is why the existing
test_overseek never surfaced this, and why my large-offset test added
no coverage that testSeek did not already provide. I have left a
comment on those two lines instead — the test's name gives no hint that
they guard a UB fix, and trimming them would silently remove the
coverage.

@picnixz — if you would still prefer an explicitly-named regression
test even though it duplicates existing coverage, say so and I will add
one back; I did not want to leave a test in that could not fail.

---

Unrelated but worth flagging, since it cost me a while and may cost
others the same. -fno-strict-overflow silently disables clang's
pointer-overflow sanitizer, and re-adding -fsanitize=pointer-overflow
afterwards does not bring it back:

-fsanitize=undefined                                          -> reports
-fsanitize=undefined -fno-strict-overflow                     -> silent
-fsanitize=undefined -fno-strict-overflow
                     -fsanitize=pointer-overflow              -> silent

--with-strict-overflow defaults to no, so an ordinary
./configure --with-undefined-behavior-sanitizer build cannot see any
pointer-overflow: finding. The CI job is fine — reusable-san.yml
passes --with-strict-overflow explicitly — but anyone reproducing a
suppressions-file entry locally with the obvious configure line will get
silence and reasonably conclude the entry is stale. I did, for several
builds, before spotting it.

@StanFromIreland this may be worth a line in Tools/ubsan/README or
next to the pointer-overflow entries, given you own that file. Happy
to send that as a separate PR if useful.