[test-results] [Bamboo] Asterisk Testing > AST1.8-digiumphones > #9 has FAILED. Change made by qwell.

[Bamboo]

-----------------------------------------------------------------------
Asterisk Testing > AST1.8-digiumphones > #9 failed.
-----------------------------------------------------------------------
Code has been updated by qwell.
2/2 jobs failed, with 0 failing tests.

http://bamboo.asterisk.org/browse/TESTING-AST18DIGIUMPHONES-9/


--------------
Failing Jobs
--------------
  - Asterisk 1.8 CentOS 6 32-Bit (CentOS 6): 68 tests passed.
  - Asterisk 1.8 CentOS 6 64-Bit (CentOS 6): 69 tests passed.


--------------
Code Changes
--------------
qwell (360826):

>Multiple revisions 359656,359706,359979
>
>........
>  r359656 | mjordan | 2012-03-15 13:35:59 -0500 (Thu, 15 Mar 2012) | 22 lines
>  
>  Fix remotely exploitable stack overrun in Milliwatt
>  
>  Milliwatt is vulnerable to a remotely exploitable stack overrun when using
>  the 'o' option.  This occurs due to the milliwatt_generate function not
>  accounting for AST_FRIENDLY_OFFSET when calculating the maximum number of
>  samples it can put in the output buffer.
>  
>  This patch resolves this issue by taking into account AST_FRIENDLY_OFFSET
>  when determining the maximum number of samples allowed.  Note that at no
>  point is remote code execution possible.  The data that is written into the
>  buffer is the pre-defined Milliwatt data, and not custom data.
>  
>  (closes issue ASTERISK-19541)
>  Reported by: Russell Bryant
>  Tested by: Matt Jordan
>  Patches:
>    milliwatt_stack_overrun.rev1.txt by Russell Bryant (license 6283)
>    Note that this patch was written by Russell, even though Matt uploaded it
>  ........
>  
>  Merged revisions 359645 from http://svn.asterisk.org/svn/asterisk/branches/1.6.2
>........
>  r359706 | mjordan | 2012-03-15 14:01:22 -0500 (Thu, 15 Mar 2012) | 16 lines
>  
>  Fix remotely exploitable stack overflow in HTTP manager
>  
>  There exists a remotely exploitable stack buffer overflow in HTTP digest
>  authentication handling in Asterisk.  The particular method in question
>  is only utilized by HTTP AMI.  When parsing the digest information, the
>  length of the string is not checked when it is copied into temporary buffers
>  allocated on the stack.
>  
>  This patch fixes this behavior by parsing out pre-defined key/value pairs
>  and avoiding unnecessary copies to the stack.
>  
>  (closes issue ASTERISK-19542)
>  Reported by: Russell Bryant
>  Tested by: Matt Jordan
>........
>  r359979 | rmudgett | 2012-03-20 12:21:16 -0500 (Tue, 20 Mar 2012) | 28 lines
>  
>  Allow AMI action callback to be reentrant.
>  
>  Fix AMI module reload deadlock regression from ASTERISK-18479 when it
>  tried to fix the race between calling an AMI action callback and
>  unregistering that action.  Refixes ASTERISK-13784 broken by
>  ASTERISK-17785 change.
>  
>  Locking the ao2 object guaranteed that there were no active callbacks that
>  mattered when ast_manager_unregister() was called.  Unfortunately, this
>  causes the deadlock situation.  The patch stops locking the ao2 object to
>  allow multiple threads to invoke the callback re-entrantly.  There is no
>  way to guarantee a module unload will not crash because of an active
>  callback.  The code attempts to minimize the chance with the registered
>  flag and the maximum 5 second delay before ast_manager_unregister()
>  returns.
>  
>  The trunk version of the patch changes the API to fix the race condition
>  correctly to prevent the module code from unloading from memory while an
>  action callback is active.
>  
>  * Don't hold the lock while calling the AMI action callback.
>  
>  (closes issue ASTERISK-19487)
>  Reported by: Philippe Lindheimer
>  
>  Review: https://reviewboard.asterisk.org/r/1818/
>  Review: https://reviewboard.asterisk.org/r/1820/
>........
>
>Merged revisions 359656,359706,359979 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>


--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20120329/71870937/attachment-0001.htm>