[Python-Dev] Potential NULL pointer dereference in descrobject.c
Hi Guys,
We've been analyzing CPython with our static analysis tool (Sentry)
and a NULL pointer dereference popped up the other day, in
Objects/descrobject.c:
if (descr != NULL) {
Py_XINCREF(type);
descr->d_type = type;
descr->d_name = PyUnicode_InternFromString(name);
if (descr->d_name == NULL) {
Py_DECREF(descr);
descr = NULL;
}
descr->d_qualname = NULL; // Possible NULL pointer dereference
}
If the inner conditional block can be reached, descr will be set NULL
and then dereferenced on the next line. The commented line above was
added in this commit: http://hg.python.org/cpython/rev/73948#l4.92
Hopefully someone can take a look and determine the appropriate fix.
Best,
Mike
--
Mike Mueller
Phone: (401) 405-1525
Email: [email protected]
http://www.vigilantsw.com/
Static Analysis for C and C++
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
ಠ_ಠ
On Sat, Dec 17, 2011 at 8:55 PM, Michael Mueller
wrote:
> Hi Guys,
>
> We've been analyzing CPython with our static analysis tool (Sentry)
> and a NULL pointer dereference popped up the other day, in
> Objects/descrobject.c:
>
> if (descr != NULL) {
> Py_XINCREF(type);
> descr->d_type = type;
> descr->d_name = PyUnicode_InternFromString(name);
> if (descr->d_name == NULL) {
> Py_DECREF(descr);
> descr = NULL;
> }
> descr->d_qualname = NULL; // Possible NULL pointer dereference
> }
>
> If the inner conditional block can be reached, descr will be set NULL
> and then dereferenced on the next line. The commented line above was
> added in this commit: http://hg.python.org/cpython/rev/73948#l4.92
>
> Hopefully someone can take a look and determine the appropriate fix.
>
> Best,
> Mike
>
> --
> Mike Mueller
> Phone: (401) 405-1525
> Email: [email protected]
>
> http://www.vigilantsw.com/
> Static Analysis for C and C++
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com
--
ಠ_ಠ
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dict for Xmas?
On Fri, Dec 16, 2011 at 11:32 PM, Terry Reedy wrote: > On 12/16/2011 5:03 AM, Mark Shannon wrote: > >> Of course using __slots__ saves more memory, >> but people don't use them much. > > > Do you think the stdlib should be using __slots__ more? Note that unlike some other more advanced approaches, slots do change semantics. There are many cases out there where people would stuff arbitrary things on stdlib objects and this works fine without __slots__, but will stop working as soon as you introduce them. A change from no slots to using slots is not only a performance issue. Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dict for Xmas?
On Sat, Dec 17, 2011 at 12:53, Maciej Fijalkowski wrote: > Note that unlike some other more advanced approaches, slots do change > semantics. There are many cases out there where people would stuff > arbitrary things on stdlib objects and this works fine without > __slots__, but will stop working as soon as you introduce them. A > change from no slots to using slots is not only a performance issue. Yeah... This whole idea reeks of polymorphic inline caches (called "shapes" or "hidden classes" in SpiderMonkey and v8, respectively), where they dynamically try to infer what kind of class an object has, such that the __slots__ optimization can be done without making it visible in the semantics. The Unladen Swallow guys mention in their ProjectPlan that the overhead of opcode fetch/dispatch makes that hard, though. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dict for Xmas?
On Sat, Dec 17, 2011 at 2:31 PM, Dirkjan Ochtman wrote: > On Sat, Dec 17, 2011 at 12:53, Maciej Fijalkowski wrote: >> Note that unlike some other more advanced approaches, slots do change >> semantics. There are many cases out there where people would stuff >> arbitrary things on stdlib objects and this works fine without >> __slots__, but will stop working as soon as you introduce them. A >> change from no slots to using slots is not only a performance issue. > > Yeah... This whole idea reeks of polymorphic inline caches (called > "shapes" or "hidden classes" in SpiderMonkey and v8, respectively), > where they dynamically try to infer what kind of class an object has, > such that the __slots__ optimization can be done without making it > visible in the semantics. The Unladen Swallow guys mention in their > ProjectPlan that the overhead of opcode fetch/dispatch makes that > hard, though. > > Cheers, > > Dirkjan It's done in PyPy btw. Works like a charm :) It's called sharing dict and the idea dates back to self and it's maps. There is also an ongoing effort to specialize on types of fields, so you don't have to box say ints stored on classes. That's however in-progress now :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
On 12/17/2011 11:33 AM, Matt Joiner wrote: > ಠ_ಠ Would you please stop this? It may have been funny the first time, but now it looks like pure trolling. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
2011/12/17 Michael Mueller : > > Hopefully someone can take a look and determine the appropriate fix. Fixed. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
In that same code, right before "PY_DECREF(descr)", should there also be a "PY_XDECREF(type)"? it looks like it might leak a reference to "type" otherwise. the line in question - http://hg.python.org/cpython/file/8c355edc5b1d/Objects/descrobject.c#l628 - Eli Collins On Sat, Dec 17, 2011 at 8:02 AM, Benjamin Peterson wrote: > 2011/12/17 Michael Mueller : > > > > Hopefully someone can take a look and determine the appropriate fix. > > Fixed. > > > -- > Regards, > Benjamin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/elic%40assurancetechnologies.com > -- Eli Collins [email protected] Software Development & I.T. Consulting Assurance Technologies www.assurancetechnologies.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IEEE/ISO draft on Python vulnerabilities
Victor: Python.3 Type System [IHN] - The use of “extended precision” as a term to express Python’s ability to create and manipulate integers of any size (within the memory limitations of the computer) is poor since that term is used in reference to floating point numbers almost exclusively. I will change it to “unlimited precision” in the revised annex. Python.16 Wrap‐around Error [XYY] - My source for this is in the Python documentation under the 2nd reference to OverflowError in: http://docs.python.org/py3k/library/exceptions.html?highlight=overflowerror Python.23 Initialization of Variables [LAV] – Point taken on the unusual syntax (I am not a Python programmer) and I will change to the more common syntax s per your 2nd suggested syntax. Python.32 Structured Programming [EWD] – The point I was trying to make was that, unlike many early languages, Python has no constructs, like the ones mentioned, that can be used to create an unstructured program. I am not advocating, nor would it be proper in this kind of paper, that the Python language be extended to allow for unstructured statements. I will try to clarify this better in the revised version. Python.51 Undefined Behaviour [EWF] #1 – I need to do more research as your example does suggest that mutating, at least, does raise an exception. Here are a few references that claim that this is undefined: Refer to (10) under: http://docs.python.org/release/2.4/lib/typesseq-mutable.html Python.51 Undefined Behaviour [EWF] #2 – In regard to collections.OrderedDict, since I am only listing undefined behaviors I don’t think adding a defined behaviour here is appropriate. Python.52 Implementation–defined Behaviour [FAB] – In regard to mixing tabs and spaces, I will add your advice to the 52.2 Guidance section Thanks for your excellent comments; the paper will be improved because of them. Kevin Coyne 703.901.6774 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
2011/12/17 Eli Collins > > In that same code, right before "PY_DECREF(descr)", should there also be a > "PY_XDECREF(type)"? it looks like it might leak a reference to "type" > otherwise. No. The descr will deallocate it. PS. Please don't send HTML mail. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
On Sat, Dec 17, 2011 at 11:20 AM, Benjamin Peterson wrote: > > No. The descr will deallocate it. > > PS. Please don't send HTML mail. > Thank you for the explanation. And my apologies to the entire list for the HTML; it's way too early for me, I forgot to turn that mess off. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
On Sat, Dec 17, 2011 at 5:02 AM, Benjamin Peterson wrote: > 2011/12/17 Michael Mueller : >> >> Hopefully someone can take a look and determine the appropriate fix. > > Fixed. > > -- > Regards, > Benjamin Excellent! -- Mike Mueller Phone: (401) 405-1525 Email: [email protected] http://www.vigilantsw.com/ Static Analysis for C and C++ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
Matt Joiner wrote: ಠ_ಠ What's up with these ?_? messages? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
On Sun, 18 Dec 2011 13:09:16 +1300
Greg Ewing wrote:
> Matt Joiner wrote:
> > ಠ_ಠ
>
> What's up with these ?_? messages?
>>> print(ascii("ಠ_ಠ"))
'\u0ca0_\u0ca0'
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
Greg Ewing wrote: Matt Joiner wrote: ಠ_ಠ What's up with these ?_? messages? I think that, depending on the typeface you view it with, it is supposed to be some sort of smiley: two big wide open square eyes with tightly pursed lips. Presumably it is supposed to be a look of shock and surprise. As smileys go, it's pretty poor, because people are unlikely to see the same thing. The supposed eyes are probably intended to be square boxes; in my email client, the boxes contain tiny 0ca0 characters, which completely ruins the effect. Apparently you see a question mark instead of a box. Depending on the typeface, others might see a full box, an empty box, a diamond with a question mark in it, nothing at all, or some other glyph. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c
Steven D'Aprano wrote: Greg Ewing wrote: Matt Joiner wrote: ಠ_ಠ What's up with these ?_? messages? I think that, depending on the typeface you view it with, it is supposed to be some sort of smiley: two big wide open square eyes with tightly pursed lips. Presumably it is supposed to be a look of shock and surprise. Apparently it is supposed to be a look of disapproval: http://knowyourmeme.com/memes/%E0%B2%A0%E0%B2%A0-look-of-disapproval and the 0c0a characters on either side of the underscore is KANNADA LETTER TTHA: http://www.fileformat.info/info/unicode/char/ca0/index.htm -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent script/console behaviour
On Fri, 23 Sep 2011 16:32:30 -0700, Guido van Rossum wrote: > You can't fix this without completely changing the way the interactive > console treats blank lines. None that it's not just that a blank line is > required after a function definition -- you also *can't* have a blank > line *inside* a function definition. > > The interactive console is optimized for people entering code by typing, > not by copying and pasting large gobs of text. > > If you think you can have it both, show us the code. Apology for the advertising, but if the OP is really interested in that kind of behavior, then instead of asking for making the default shell more complex, he can use ipython which supports what he's looking for: In [5]: def some(): ...: print 'xxx' ...: some() ...: xxx and even blank lines inside functions (albeit only in certain locations): In [6]: def some(): ...: ...: print 'xxx' ...: some() ...: xxx Now, the dances we have to do in ipython to achieve that are much more complex than what would be reasonable to have in the default '>>>' python shell, which should remain simple, light and robust. But ipython is a simple install for someone who wants fancier features for interactive work. Cheers, f ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
