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=64114&r2=64113

- audioop_tostereo - should be fine, but relies on undefined behaviour
- audioop_lin2lin - undetected overflow: size=1, size2=4, len=0x40000001
- audioop_ratecv - undetected overflow: nchannels=0x5fffffff (32bit)
- audioop_ulaw2lin - undetected overflow: size=4, len=0x40000001
- audioop_alaw2lin - same as audioop_ulaw2lin
- audioop_adpcm2lin - undetected overflow: size=4, len=0x20000001

Most of these are triggered by large fragment as an input.

Attached patch replaces checks added in r64114 by checks using INT_MAX.

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 to add them to Lib/test/test_audioop.py as extra testcases.

One other question:  is there something about the formats that audioop is dealing with that limits sizes to INT_MAX (rather than PY_SSIZE_T_MAX, for example)?  I'm not really familiar with audio formats.

As an aside, I also find it strange that the code raises MemoryError in these cases, since these exceptions can be raised even when there's plenty of memory available.  IMO MemoryError should only be raised as a result of a failed attempt to allocate memory from the system.  Some other exception---perhaps OverflowError---would seem more appropriate here.

Unless you have an explicit exploit, I think the 'type' should be 'behavior' rather than 'security'.

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 should be changed in py3k, though.

I'll review this patch and (assuming it looks good) apply it to the 2.x branches.  It would be great to have some tests, though.

> 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 the same commit r64114.

Having another close look, I can reproduce crash with lin2lin:
  audioop.lin2lin("A"*0x40000001, 1, 4)

ratecv may cause issues too.  Other cases use for loop with multiplication product as an upper bound, so the integer overflow should be harmless in those case.

> is there something about the formats that audioop is dealing
> with that limits sizes to INT_MAX (rather than PY_SSIZE_T_MAX,
> for example)?

I've started looking into this on oldish python 2.4, where PyString_FromStringAndSize accepts int size, rather than Py_ssize_t.  Rest of the audioop code was using ints too.  It's possible it is ok to more to size_t in current python version.

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 another issue for the int->Py_ssize_t changes.

Thanks again for the patch!

Fixed one more bogus overflow check in r81079 through r81082.