Mark Dickinson dicki...@gmail.com added the comment:
Fixed one more bogus overflow check in r81079 through r81082.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8674
___
New submission from Tomas Hoger tho...@redhat.com:
SVN commit r64114 added integer overflow checks to multiple modules. Checks
added to audioop module are incorrect and can still be bypassed:
http://svn.python.org/view/python/trunk/Modules/audioop.c?r1=64114r2=64113
- audioop_tostereo -
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the patch. I agree that undefined behaviour (e.g., from signed
overflow) should be avoided where at all possible.
Do you have any Python examples that failed to trigger the overflow on your
platform? If so, it would be useful
Mark Dickinson dicki...@gmail.com added the comment:
Unless you have an explicit exploit, I think the 'type' should be 'behavior'
rather than 'security'.
--
stage: - unit test needed
type: security - behavior
versions: +Python 2.7, Python 3.1, Python 3.2
Mark Dickinson dicki...@gmail.com added the comment:
Okay, it looks to me as though all those 'int' lengths should really be
'Py_ssize_t'. I don't think that's something we can change in 2.6, though;
probably not in 2.7 either, since we're getting too close to the release. It
can and
Tomas Hoger tho...@redhat.com added the comment:
Do you have any Python examples that failed to trigger the overflow
on your platform?
No, I've not really tried to create some, as I found it while looking into
similar checks added to rgbimg module (which is dead and removed upstream now)
in
Mark Dickinson dicki...@gmail.com added the comment:
Yes, writing portable tests turns out to be tricky; I also don't want to write
tests based on int that'll fail when/if Py_ssize_t is substituted.
Applied the patch (with a couple of minor changes) in r81045 through r81048.
I'll open
