gh-151763: Fix NULL deref in os._path_normpath()#151779
Conversation
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
os._path_normpath()
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Thanks @zainnadeem786 for the PR, and @StanFromIreland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13. |
|
Thanks @zainnadeem786 for the PR, and @StanFromIreland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14. |
|
Thanks @zainnadeem786 for the PR, and @StanFromIreland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15. |
|
GH-152094 is a backport of this pull request to the 3.13 branch. |
|
GH-152095 is a backport of this pull request to the 3.14 branch. |
|
GH-152096 is a backport of this pull request to the 3.15 branch. |
|
Merged, thanks. |
|
Thanks! @StanFromIreland I really appreciate your review and guidance throughout the process. It was great working with you, and I look forward to contributing more fixes and PRs in the future. |
Summary
This PR addresses OOM-0028 from gh-151763.
It fixes a NULL dereference in
os__path_normpath_impl()when memory allocation fails while normalizing a bytes path.Issue
os__path_normpath_impl()builds a Unicoderesultusing eitherPyUnicode_FromOrdinal()orPyUnicode_FromWideChar().For bytes input, the function then converts that Unicode result back to bytes using
PyUnicode_EncodeFSDefault().Before this change, the result of
PyUnicode_FromWideChar()was not checked before the bytes-path encoding branch.Under memory pressure,
PyUnicode_FromWideChar()can returnNULLwith a pendingMemoryError. The existing code could then pass thatNULLvalue intoPyUnicode_EncodeFSDefault(), causing a crash.Fix
Add an explicit NULL check immediately after creating
resultand before the bytes-path encoding branch.This preserves the pending
MemoryErrorand preventsPyUnicode_EncodeFSDefault()from receiving a NULL object.Validation
I validated this using a CPython debug build on Windows:
Then I used
_testcapi.set_nomemory()to inject allocation failures while calling:Before the fix
With the NULL guard removed, allocation index
2crashed:3221225477is0xC0000005, WindowsSTATUS_ACCESS_VIOLATION.After the fix
With the NULL guard restored, the same allocation index returned a clean
MemoryErrorinstead of crashing:This confirms that the failing OOM path now propagates the allocation failure instead of dereferencing NULL.
Tests
Focused
ntpathtests passed:Result:
I also checked the patch with:
No regression test is included in this PR. The OOM reproducer depends on allocation-failure injection and allocation indexes that can be build-sensitive. The fix itself is a minimal local NULL guard.
Addresses OOM-0028 from gh-151763.