[issue46280] About vulnerabilities in Cpython native code

miss-islington added the comment: New changeset ae6e255cb362557ff713ff2967aecb92f7eb069c by Miss Islington (bot) in branch '3.9': bpo-46280: Fix tracemalloc_copy_domain() (GH-30591) https://github.com/python/cpython/commit/ae6e255cb362557ff713ff2967aecb92f7eb069c --

[issue46280] About vulnerabilities in Cpython native code

miss-islington added the comment: New changeset 86d18019e96167c5ab6f5157fa90598202849904 by Miss Islington (bot) in branch '3.10': bpo-46280: Fix tracemalloc_copy_domain() (GH-30591) https://github.com/python/cpython/commit/86d18019e96167c5ab6f5157fa90598202849904 --

[issue46280] About vulnerabilities in Cpython native code

Change by miss-islington : -- pull_requests: +28791 pull_request: https://github.com/python/cpython/pull/30593 ___ Python tracker ___

[issue46280] About vulnerabilities in Cpython native code

Change by miss-islington : -- nosy: +miss-islington nosy_count: 7.0 -> 8.0 pull_requests: +28790 pull_request: https://github.com/python/cpython/pull/30592 ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

STINNER Victor added the comment: New changeset 7c770d3350813a82a639fcb3babae0de2b87aaae by Victor Stinner in branch 'main': bpo-46280: Fix tracemalloc_copy_domain() (GH-30591) https://github.com/python/cpython/commit/7c770d3350813a82a639fcb3babae0de2b87aaae --

[issue46280] About vulnerabilities in Cpython native code

STINNER Victor added the comment: #389 Modules/_tracemalloc.c:1245: error: Null Dereference pointer `traces2` last assigned on line 1243 could be null and is dereferenced by call to `_Py_hashtable_destroy()` at line 1245, column 9. 1243. _Py_hashtable_t *traces2 =

[issue46280] About vulnerabilities in Cpython native code

Change by STINNER Victor : -- nosy: +vstinner nosy_count: 6.0 -> 7.0 pull_requests: +28789 pull_request: https://github.com/python/cpython/pull/30591 ___ Python tracker ___

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: Update on #324 and #325. Not only are these false positives, but Serhiy pointed-out the existing logic is intentional and should not be rewritten. -- ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +28651 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30445 ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #654 is a false positive. The value of ptrs[0] is initialized to NULL via a pointer alias a few lines before: pp = ptrs; ... *pp = NULL; ... if (ptrs[0] == NULL) -- ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #632 should be left as is. Technically, the second "field++" is a dead store. However, it is harmless and has some advantages. It keeps the the assignments parallel and it reduces the chance of introducing a new bug if a new field is added (i.e. like

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #606 is similar to #584 and #585. The "dead store" is used only in an assertion: have_dict = 1;<== Presumed dead store } assert(have_dict);<== Used in an assert In the case, it would be reasonable to add an #ifdef.

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #584 and #585: The code is correct but there are dead stores only when the asserts are turned off: 2635. carry = v_lshift(w->ob_digit, w1->ob_digit, size_w, d); 2636. assert(carry == 0); Elsewhere we use ifdefs around code like this to

[issue46280] About vulnerabilities in Cpython native code

Serhiy Storchaka added the comment: The CPython source code is irregularly scanned by different code analysis tools. The results shown extremely high quality of code in comparison with other open source and proprietary code. Most of reports are false positive. Last time real bugs (2 or 3)

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #533, #534, #535, and #536 are false positives for the same reason as #511 and #512. The two "dead stores" in 533 and 534 match the "uninitialized variables" in 535 and 536. -- ___ Python tracker

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #511 and #512 are false positives. The "kind" variable is indeed uninitialized in the bytes_writer case: else if (bytes_writer) { *bytes_str = _PyBytesWriter_Prepare(bytes_writer, *bytes_str, strlen); if (*bytes_str == NULL) {

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: The dead store notices for all the DISPATCH calls in ceval.c are false positives. The "oparg" value is used in many of the case statements. The dead store notices the clinic generated code all relate to "!--noptargs" which is sometimes used in generated

[issue46280] About vulnerabilities in Cpython native code

Pablo Galindo Salgado added the comment: > Anyway, (if I'm right,) this makes my points that a) there are false > positives, and b) we should have separate issues for each actual problem. Sorry Eric, I failed to clarify my comment: you are absolutely right in your analysis. I was trying to

[issue46280] About vulnerabilities in Cpython native code

Change by Zachary Ware : -- nosy: +414039482 -zach.ware ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46280] About vulnerabilities in Cpython native code

Terry J. Reedy added the comment: Last I knew, CPython C code is a) regularly scanned by Valgrind and b) Valgrind is somehow informed as to false positives to not report. But I know none of the details. So I suggest you look into this and how to not report the same false positives. I

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #420 and #421 are false positives. The value of "c" is initialized a few lines before use. for (;;) { c = tok_nextc(tok); ... } ... tok_backup(tok, c); if (c == '#' || c == '\n' || c ==

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #382 is false positive. The "iterable" variable is only accessed when known to not be NULL. # Line 970 if (iterable != NULL) { if (set_update_internal(so, iterable)) { Py_DECREF(so); return NULL; } }

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #324 and #325 are false positives. The result variable is initialized in the preceding lines: if (len_a == length) { left = *((volatile const unsigned char**)); result = 0; } if (len_a != length) { left = b;

[issue46280] About vulnerabilities in Cpython native code

Eric V. Smith added the comment: I don't want to belabor this, but hey, it's in f-strings! And if it's an actual problem I'd like to fix it. > It can be uninitialized if the parenstack[nested_depth] value is itself > initialized, which can happen if the memory block pointed by parenstack

[issue46280] About vulnerabilities in Cpython native code

Raymond Hettinger added the comment: #244 is a false positive. The value of new_state[i] on line 454 was initialized on line 442 with: new_state[i] = (uint32_t)element. #387 is also a false positive. There is an assertion on the previous line that the item != NULL. That assertion passes

[issue46280] About vulnerabilities in Cpython native code

Pablo Galindo Salgado added the comment: > I don't see how this could be an uninitialized read, although I'm willing to > be wrong. It can be uninitialized if the parenstack[nested_depth] value is itself initialized, which can happen if the memory block pointed by parenstack has not been

[issue46280] About vulnerabilities in Cpython native code

Joannah Nanjekye added the comment: > You mention here that your tool automatically "repairs" the code. Could you > >submit a sample PR with the repairs that your tool does so we can evaluate > it? I second this. I obviously, am assuming good intentions from the author, not experimenting

[issue46280] About vulnerabilities in Cpython native code

Zachary Ware added the comment: As an aside, there's an issue with Roundup where a username composed of all digits causes it to think that name is a user ID in the nosy list. I recommend changing your username to include a non-digit character so that others can interact with you on your

[issue46280] About vulnerabilities in Cpython native code

Change by Zachary Ware : -- nosy: +414039482 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46280] About vulnerabilities in Cpython native code

Pablo Galindo Salgado added the comment: > Based on the research of the result, I tried to design a tool to > automatically detect and repair vulnerabilities in CPython and make this tool > available. See: You mention here that your tool automatically "repairs" the code. Could you submit a

[issue46280] About vulnerabilities in Cpython native code

Eric V. Smith added the comment: Thank you for posting this. Some of these look like false positives. For example: #263 Parser/string_parser.c:670: error: Uninitialized Value The value read from parenstack[_] was never initialized. 668. } 669. nested_depth--;

[issue46280] About vulnerabilities in Cpython native code

New submission from Xinrong Lin <414039...@qq.com>: I am currently doing some research on the security of CPython. I used the open source vulnerability analysis engine, Infer(https://fbinfer.com/), to scan the native code of CPython 3.10.0. The scan results show that there are still a