Content-Length: 313616 | pFad | http://github.com/python/cpython/pull/132574/commits/f0d20b254e2444632cdaea2552078ef5399ed0ad

B0 gh-127971: fix off-by-one read beyond the end of a string during search by duaneg · Pull Request #132574 · python/cpython · GitHub
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.

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
Changes from 1 commit
Commits
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
Next Next commit
gh-127971: do not read past the end of a string
Fix off-by-one read beyond the end of a string.
  • Loading branch information
duaneg committed Apr 15, 2025
commit f0d20b254e2444632cdaea2552078ef5399ed0ad
4 changes: 2 additions & 2 deletions Objects/stringlib/fastsearch.h
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

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








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://github.com/python/cpython/pull/132574/commits/f0d20b254e2444632cdaea2552078ef5399ed0ad

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy