Skip to content

[3.15] gh-151297: Fix undefined behavior in _PyObject_MiRealloc (GH-151358)#151388

Merged
ZeroIntensity merged 1 commit into
python:3.15from
miss-islington:backport-c375992-3.15
Jun 12, 2026
Merged

[3.15] gh-151297: Fix undefined behavior in _PyObject_MiRealloc (GH-151358)#151388
ZeroIntensity merged 1 commit into
python:3.15from
miss-islington:backport-c375992-3.15

Conversation

@miss-islington

@miss-islington miss-islington commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

The standard says that a call to memcpy must pass a valid source and
destination pointer even if the size is 0, so we must avoid calling
memcpy when our source pointer is NULL. If we don't, an optimizing
compiler can decide that the pointer must be non-NULL based on the
presence of UB, and optimize out checks for null pointers.

Specifically, note that the standard says:

Where an argument declared as size_t n specifies the length of the
array for a function, n can have the value zero on a call to that
function. Unless explicitly stated otherwise in the description of
a particular function in this subclause, pointer arguments on such
a call shall still have valid values, as described in 7.1.4.

And section 7.1.4 says:

If an argument to a function has an invalid value (such as a value
outside the domain of the function, or a pointer outside the address
space of the program, or a null pointer, or a pointer to
non-modifiable storage when the corresponding parameter is not
const-qualified) or a type (after default argument promotion) not
expected by a function with a variable number of arguments, the
behavior is undefined.

The specification for memcpy doesn't state that it's allowed to be
called with null pointers, and Linux's /usr/include/string.h declares
memcpy as __nonnull ((1, 2)).
(cherry picked from commit c375992)

Co-authored-by: Matt Wozniski mwozniski@bloomberg.net

Peter testing something: Closes #151297

…honGH-151358)

The standard says that a call to `memcpy` must pass a valid source and
destination pointer even if the size is 0, so we must avoid calling
`memcpy` when our source pointer is NULL. If we don't, an optimizing
compiler can decide that the pointer must be non-NULL based on the
presence of UB, and optimize out checks for null pointers.

Specifically, note that the standard says:

    Where an argument declared as size_t n specifies the length of the
    array for a function, n can have the value zero on a call to that
    function. Unless explicitly stated otherwise in the description of
    a particular function in this subclause, pointer arguments on such
    a call shall still have valid values, as described in 7.1.4.

And section 7.1.4 says:

    If an argument to a function has an invalid value (such as a value
    outside the domain of the function, or a pointer outside the address
    space of the program, or a null pointer, or a pointer to
    non-modifiable storage when the corresponding parameter is not
    const-qualified) or a type (after default argument promotion) not
    expected by a function with a variable number of arguments, the
    behavior is undefined.

The specification for `memcpy` doesn't state that it's allowed to be
called with null pointers, and Linux's `/usr/include/string.h` declares
`memcpy` as `__nonnull ((1, 2))`.
(cherry picked from commit c375992)

Co-authored-by: Matt Wozniski <mwozniski@bloomberg.net>
@ZeroIntensity ZeroIntensity enabled auto-merge (squash) June 12, 2026 01:25
@ZeroIntensity ZeroIntensity merged commit a2e5516 into python:3.15 Jun 12, 2026
55 checks passed
@miss-islington miss-islington deleted the backport-c375992-3.15 branch June 12, 2026 01:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants