-
-
Notifications
You must be signed in to change notification settings - Fork 32k
bpo-35214: Fix OOB memory access in unicode escape parser #10506
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
Conversation
Discovered using clang's MemorySanitizer when it ran test_fstring's test_misformed_unicode_character_name. An f-string ending in `\N` would access one byte beyond the end of the string while looking for a potential `}`.
actually my news entry and description may not be correct. this may not be specific to f-strings but to any unicode string escape parsing? |
Confirmed, this is in the unicode parser, not f-string related. that just happened to be the unittest that triggered it.
|
In terms of severity, this was only ever a single byte read. The code path it entered if that byte happened to be a } did check the bounds and would result in the desired error message (which is why this went unnoticed for so long). With most memory allocations it is unlikely that this byte would be on an unmapped page and crash the program, though I suspect it would be possible to trigger that by using a large enough string to generate such a specific allocation. At most that is a crash of an interpreter from an errant memory read. Denial of service at best if someone is handing user data to the unicode escape parser. |
Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.6, 3.7. |
…0506) Discovered using clang's MemorySanitizer when it ran python3's test_fstring test_misformed_unicode_character_name. An msan build will fail by simply executing: ./python -c 'u"\N"' (cherry picked from commit 746b2d3) Co-authored-by: Gregory P. Smith <[email protected]>
GH-10522 is a backport of this pull request to the 3.7 branch. |
GH-10523 is a backport of this pull request to the 3.6 branch. |
Sorry, @gpshead, I could not cleanly backport this to |
…0506) Discovered using clang's MemorySanitizer when it ran python3's test_fstring test_misformed_unicode_character_name. An msan build will fail by simply executing: ./python -c 'u"\N"' (cherry picked from commit 746b2d3) Co-authored-by: Gregory P. Smith <[email protected]>
Discovered using clang's MemorySanitizer when it ran python3's test_fstring test_misformed_unicode_character_name. An msan build will fail by simply executing: ./python -c 'u"\N"' (cherry picked from commit 746b2d3) Co-authored-by: Gregory P. Smith <[email protected]>
…0506) (GH-10522) Discovered using clang's MemorySanitizer when it ran python3's test_fstring test_misformed_unicode_character_name. An msan build will fail by simply executing: ./python -c 'u"\N"' (cherry picked from commit 746b2d3) Co-authored-by: Gregory P. Smith <[email protected]> https://bugs.python.org/issue35214
GH-10538 is a backport of this pull request to the 2.7 branch. |
…0506) (GH-10538) Discovered using clang's MemorySanitizer. A msan build will fail by simply executing: ./python -c 'u"\N"' (cherry picked from commit 746b2d3) Co-authored-by: Gregory P. Smith <[email protected]> [Google LLC]
Discovered using clang's MemorySanitizer when it ran
test_fstring
'stest_misformed_unicode_character_name
.An f-string ending in
\N
would access one byte beyond the end ofthe string while looking for a potential
}
.https://bugs.python.org/issue35214