-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
Use After Free in initContext(_lsprof.c) #120289
Comments
I cannot reproduce it using your example on current main branch, debug build, macOS. |
The same, I cannot reproduce the issue with the poc code for O3 or debug build in Linux with main branch |
Confirmed on So this is a very rare case, or rather an explicit case to crash the profiler. I can't think of any real use case where stopping a profiler inside the timer function makes sense. It's a very interesting hack, but not that meaningful in the real world. We can do some heuristics to check this rare case, but the profiler itself is kind of performance sensitive. I don't want to make it any slower in most real-world cases. So I'll make a PR to detect if an external timer changes the profiler context and if so, write a warning (unraisable exception). This way the user would know that they are doing something crazy. There's no way for us to propagate the exception from there because it returns a time. This has no effect in normal cases where an internal timer is used. I think this is a good middle ground to address this issue. I believe even with the evil code, in most case this won't crash because the memory is not really "freed". You need ASAN to report this. So having an extra exception look reasonable to me. The alternative is to do a |
Oh we actually do have an ASAN check. Maybe I'll have to make it work with ASAN. |
After some investigation on this. I don't believe there's a quick and clean fix to check this. I think the best way is not to free the memory of profile context when the profiler is disabled. Only free when the profiler itself is released. I made the PR and it fixed the issue. |
…prevent use-after-free (pythonGH-120297) (cherry picked from commit 1ab1778) Co-authored-by: Tian Gao <[email protected]>
Fixed in main and 3.12 and 3.13. |
…prevent use-after-free (pythonGH-120297) (cherry picked from commit 1ab1778) Co-authored-by: Tian Gao <[email protected]>
…ythonGH-121998) (cherry picked from commit eaf094c) Co-authored-by: Tian Gao <[email protected]>
…ythonGH-121998) (cherry picked from commit eaf094c) Co-authored-by: Tian Gao <[email protected]>
Crash report
What happened?
Version
Python 3.14.0a0 (heads/main:34f5ae69fe, Jun 9 2024, 21:27:54) [GCC 11.4.0]
bisect from commit 2158977
Root Cause
The
call_timer
function can execute arbitrary code frompObj
, which is initialized by the user. If the code calls_lsprof_type_Profiler_post1.disable()
in Python, it will hitprofiler_disable
in C. Then, theself
(ProfileContext) will be freed. Consequently, after call_timer returns,self->t0
will cause a use-after-free error.POC
ASAN
asan
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
Python 3.14.0a0 (heads/main:34f5ae69fe, Jun 9 2024, 21:27:54) [GCC 11.4.0]
Linked PRs
The text was updated successfully, but these errors were encountered: