8000 gh-127971: fix off-by-one read beyond the end of a string during search by duaneg · Pull Request #132574 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

gh-127971: fix off-by-one read beyond the end of a string during search #132574

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jul 13, 2025
Merged

gh-127971: fix off-by-one read beyond the end of a string during search #132574

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
f0d20b2
gh-127971: do not read past the end of a string
duaneg Apr 15, 2025
462dddf
Add test case
duaneg Apr 16, 2025
1d0210a
Add blurb
duaneg Apr 16, 2025
212452d
Add test case for adaptive_find and comments better explaining the re…
duaneg Jun 21, 2025
c07c23e
Tweak conditional phrasing to match loop terminating criteria, add co…
duaneg Jun 21, 2025
338f32d
Address more reviewer feedback: add conditional to adaptive find, tweak
duaneg Jul 12, 2025
9884ec1
Always run test, not just under ASAN
duaneg Jul 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions Lib/test/string_tests.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -767,6 +767,13 @@ def test_replace(self):
self.checkraises(TypeError, 'hello', 'replace', 42, 'h')
self.checkraises(TypeError, 'hello', 'replace', 'h', 42)

# gh-127971
any_3_nonblank_codepoints = '!!!'
seven_codepoints = any_3_nonblank_codepoints + ' ' + any_3_nonblank_codepoints
a = (' ' * 243) + seven_codepoints + (' ' * 7)
b = ' ' * 6 + chr(256)
a.replace(seven_codepoints, b)

def test_replace_uses_two_way_maxcount(self):
# Test that maxcount works in _two_way_count in fastsearch.h
A, B = "A"*1000, "B"*1000
Expand Down
1 change: 1 addition & 0 deletions Misc/NEWS.d/next/Core_and_Builtins/2025-04-16-12-01-13.gh-issue-127971.pMDOQ0.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Fix off-by-one read beyond the end of a string in string search
4 changes: 2 additions & 2 deletions Objects/stringlib/fastsearch.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -595,7 +595,7 @@ STRINGLIB(default_find)(const STRINGLIB_CHAR* s, Py_ssize_t n,
continue;
}
/* miss: check if next character is part of pattern */
if (!STRINGLIB_BLOOM(mask, ss[i+1])) {
if (i < w && !STRINGLIB_BLOOM(mask, ss[i+1])) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm totally not sure that else branch is appropiate here for 'i == w2.
Even since we have i > w for this m this logic isn't clear for me.
What about simple replacement i <= w for loop condition with classical i < w?
It could be enough and cleaner.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the else branch will be OK, since all it does is advance the index, and it is intended and expected that this could potentially advance it past the end of the string, in which case the for loop will terminate.

We can't just replace the the loop condition with i < w since the w here is the last valid index that the pattern could appear at, and needs to be checked. Otherwise we would miss valid matches, and indeed such a change breaks a large number of unit tests.

Note the conditionals that were changed are miss conditions, i.e. the algorithm has determined the character at the index cannot be part of the pattern at this location in the string. The conditionals modified are checking whether the following character could potentially be part of a pattern hit, so as to determine whether to skip it entirely by advancing the full length of the pattern or only as much as possible while still considering it as a valid potential hit. In the case where we are at the end of the buffer it doesn't actually matter which branch we take, since either way it will advance past it and terminate. We just need to avoid reading the invalid following character when it doesn't exist.

Copy link
Contributor
@efimov-mikhail efimov-mikhail Jun 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's better to rewrite condition as i+1 <= w? It seems to be more obvious way of checking for me.
It's very similar to "for" condition, but for another argument and before direct using of i+1 as index.

... the w here is the last valid index that the pattern could appear at

IMO, rewrited condition slightly reduces cognitive load.

i = i + m;
}
else {
Expand All @@ -604,7 +604,7 @@ STRINGLIB(default_find)(const STRINGLIB_CHAR* s, Py_ssize_t n,
}
else {
/* skip: check if next character is part of pattern */
if (!STRINGLIB_BLOOM(mask, ss[i+1])) {
if (i < w && !STRINGLIB_BLOOM(mask, ss[i+1])) {
i = i + m;
}
}
Expand Down
Loading
0