[asterisk-dev] AST-2008-010: Asterisk IAX 'POKE' resource exhaustion

[Nic Bellamy]

Tilghman Lesher wrote:
> On Wednesday 23 July 2008 16:30:23 Nic Bellamy wrote:
>> However, in find_callno() when we allocate a new callno...
>>
>> start = 1 + (rand() % (TRUNK_CALL_START - 1));
>> for (x = start; 1; x++) {
>> ...
>> }
>>
>> As rand() gives us a number between 0 and RAND_MAX, does this not leave
>> a small but non-zero chance that we'll pick a callno of #1 for our side,
>> that will then have all its ACKs ignored?
>>
>> (I'm completely open to the possibility that other code paths prevent
>> this, but I didn't see them :-)
>
> You quoted chunk 4 of the patch, but you missed chunk 2.  Chunk 2 does what
> you think we've missed.

I presume you're meaning this part in find_callno():

                /* Look for an existing connection first */
-               for (x=1;(res < 1) && (x<maxnontrunkcall);x++) {
+               for (x=2;(res < 1) && (x<maxnontrunkcall);x++) {

That's in the "if (new <= NEW_ALLOW) {...}" path, and stops it matching 
inbound frames to callno #1.

The following "if ((res < 1) && (new >= NEW_ALLOW)) {...}" path can 
still *create* a source callno of #1 that will then have its responses 
ignored, as the first path won't find them, eg.

Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: 
NEW   
   Timestamp: 00004ms  SCall: 00001  DCall: 00000 [192.168.1.144:4569]
                              ^^^^^ "chan_iax2.c: Creating new call 
structure 1"
   VERSION         : 2
   CALLED NUMBER   : 156
   CODEC_PREFS     : (alaw)
   CALLING PRESNTN : 67
   CALLING TYPEOFN : 0
   CALLING TRANSIT : 0
   LANGUAGE        : en
   CALLED CONTEXT  : from-internal
   FORMAT          : 8
   CAPABILITY      : 63496
   ADSICPE         : 0
   DATE TIME       : 2008-07-24  12:07:50

    -- Called iaxtest/156
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: 
ACCEPT
   Timestamp: 00006ms  SCall: 09259  DCall: 00001 [192.168.1.144:4569]
   FORMAT          : 8

Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: 
INVAL 
   Timestamp: 00000ms  SCall: 00001  DCall: 09259 [192.168.1.144:4569]

^^^^ chunk #2 of the patch that stops it matching callno #1 causes an 
INVAL to be sent for the ACCEPT.

Does this look like a valid fix (in find_callno() - ignore my local SVN 
revision numbers)?

--- channels/chan_iax2.c        (revision 2570)
+++ channels/chan_iax2.c        (working copy)
@@ -1318,7 +1318,7 @@
 
                gettimeofday(&now, NULL);
 
-               start = 1 + (rand() % (TRUNK_CALL_START - 1));
+               start = 2 + (rand() % (TRUNK_CALL_START - 2));
                for (x = start; 1; x++) {
                        if (x == TRUNK_CALL_START) {
                                x = 0;

I tested my theory by forcing the issue - setting "start = 1;" above.

Cheers,
    Nic.

-- 
Nic Bellamy,
Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/