Fix GH-23106: mb_strpos() reads past the end of a truncated UTF-8 haystack - #23107
Open
lazerg wants to merge 1 commit into
Open
Fix GH-23106: mb_strpos() reads past the end of a truncated UTF-8 haystack#23107lazerg wants to merge 1 commit into
lazerg wants to merge 1 commit into
Conversation
lazerg
force-pushed
the
fix/gh-23106-mb-strpos-offset
branch
from
August 7, 2026 18:11
1f7b65b to
ae9db77
Compare
Contributor
|
Thanks for the good catch! I just need to study the code a bit and confirm if the right thing to do here is to clamp or to return NULL. |
Contributor
Author
Okay, let me know if you have suggestions.. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
offset_to_pointer_utf8()walks the haystack with the UTF-8 mblen table. If the string ends in a truncated multi-byte sequence, the table length for the lead byte is larger than the bytes actually left, so the walk returns a pointer past the end of the string.mb_strpos()passes that pointer tozend_memnstr()as the start of the search, which fails theend >= passertion on a debug build.On a release build it is an out-of-bounds read instead:
mb_strpos("AA\xf0\x90", "x", 3)returns a different bogus offset on every run, and with a long enough haystack it segfaults.The clamp is the one
mb_str_split()already uses for the same mblen table walk.Fixes GH-23106