Skip to content

Check tokens[0] after allocating memory #95355

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

Closed
imzhuhl opened this issue Jul 28, 2022 · 4 comments
Closed

Check tokens[0] after allocating memory #95355

imzhuhl opened this issue Jul 28, 2022 · 4 comments
Labels
3.10 only security fixes 3.11 only security fixes 3.12 only security fixes type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@imzhuhl
Copy link
Contributor

imzhuhl commented Jul 28, 2022

Bug report

I have questions when reading the source code of file pegen.c.
There is a code snippet in function _PyPegen_Parser_New:

p->tokens[0] = PyMem_Calloc(1, sizeof(Token));
if (!p->tokens) {
    PyMem_Free(p->tokens);
    PyMem_Free(p);
    return (Parser *) PyErr_NoMemory();
}

I think it makes more sense to check p->tokens[0] but not p->tokens in if condition.

I look at the PR #19669 where the code was introduced and no one discussed this. Is this an oversight, or am I wrong?

Your environment

  • CPython versions tested on: main branch
@imzhuhl imzhuhl added the type-bug An unexpected behavior, bug, or error label Jul 28, 2022
imzhuhl added a commit to imzhuhl/cpython that referenced this issue Jul 28, 2022
@arhadthedev
Copy link
Member

arhadthedev commented Jul 28, 2022

@AlexWaygood It seems to be a type-crash since PyMem_Calloc() failure is ignored leading to a C null pointer access somewhere below.

@AlexWaygood
Copy link
Member

@AlexWaygood It seems to be a type-crash since PyMem_Calloc() failure is ignored leading to a C null pointer access somewhere below.

Sounds plausible, but I'm not much of a C programmer, so I'll let somebody else do the relabelling :)

miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jul 28, 2022
pythonGH-95355

Automerge-Triggered-By: GH:pablogsal
(cherry picked from commit b946f52)

Co-authored-by: Honglin Zhu <[email protected]>
miss-islington pushed a commit that referenced this issue Jul 28, 2022
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jul 28, 2022
pythonGH-95355

Automerge-Triggered-By: GH:pablogsal
(cherry picked from commit b946f52)

Co-authored-by: Honglin Zhu <[email protected]>
miss-islington added a commit that referenced this issue Jul 28, 2022
GH-95355

Automerge-Triggered-By: GH:pablogsal
(cherry picked from commit b946f52)

Co-authored-by: Honglin Zhu <[email protected]>
@kumaraditya303 kumaraditya303 added 3.11 only security fixes 3.10 only security fixes 3.12 only security fixes type-crash A hard crash of the interpreter, possibly with a core dump labels Jul 28, 2022
miss-islington added a commit that referenced this issue Jul 28, 2022
GH-95355

Automerge-Triggered-By: GH:pablogsal
(cherry picked from commit b946f52)

Co-authored-by: Honglin Zhu <[email protected]>
@kumaraditya303
Copy link
Contributor

Sounds plausible, but I'm not much of a C programmer, so I'll let somebody else do the relabelling :)

Ok done, it can indeed segfault if allocation fails, classic null dereference :)

@kumaraditya303
Copy link
Contributor

Fixed by #95356, thanks for the report!

@AlexWaygood AlexWaygood removed the type-bug An unexpected behavior, bug, or error label Jul 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.10 only security fixes 3.11 only security fixes 3.12 only security fixes type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

4 participants