Skip to content
Snippets Groups Projects
  1. Jan 02, 2013
    • Automerge script's avatar
      Merged revisions 378374,378377,378384 via svnmerge from · b375abae
      Automerge script authored
      file:///srv/subversion/repos/asterisk/trunk
      
      ................
        r378374 | rmudgett | 2013-01-02 15:23:16 -0600 (Wed, 02 Jan 2013) | 33 lines
        
        Fix AMI redirect action with two channels failing to redirect both channels.
        
        The AMI redirect action can fail to redirect two channels that are bridged
        together.  There is a race between the AMI thread redirecting the two
        channels and the bridge thread noticing that a channel is hungup from the
        redirects.
        
        * Made the bridge wait for both channels to be redirected before exiting.
        
        * Made the AMI redirect check that all required headers are present before
        proceeding with the redirection.
        
        * Made the AMI redirect require that any supplied ExtraChannel exist
        before proceeding.  Previously the code fell back to a single channel
        redirect operation.
        
        (closes issue ASTERISK-18975)
        Reported by: Ben Klang
        
        (closes issue ASTERISK-19948)
        Reported by: Brent Dalgleish
        Patches:
              jira_asterisk_19948_v11.patch (license #5621) patch uploaded by rmudgett
        Tested by: rmudgett, Thomas Sevestre, Deepak Lohani, Kayode
        
        Review: https://reviewboard.asterisk.org/r/2243/
        ........
        
        Merged revisions 378356 from http://svn.asterisk.org/svn/asterisk/branches/1.8
        ........
        
        Merged revisions 378358 from http://svn.asterisk.org/svn/asterisk/branches/11
      ................
        r378377 | mjordan | 2013-01-02 16:10:32 -0600 (Wed, 02 Jan 2013) | 24 lines
        
        Prevent crashes from occurring when reading from data sources with large values
        
        When reading configuration data from an Asterisk .conf file or when pulling
        data from an Asterisk RealTime backend, Asterisk was copying the data on the
        stack for manipulation. Unfortunately, it is possible to read configuration
        data or realtime data from some data source that provides a large blob of
        characters. This could potentially cause a crash via a stack overflow.
        
        This patch prevents large sets of data from being read from an ARA backend or
        from an Asterisk conf file.
        
        (issue ASTERISK-20658)
        Reported by: wdoekes
        Tested by: wdoekes, mmichelson
        patches:
         * issueA20658_dont_process_overlong_config_lines.patch uploaded by wdoekes (license 5674)
         * issueA20658_func_realtime_limit.patch uploaded by wdoekes (license 5674)
        ........
        
        Merged revisions 378375 from http://svn.asterisk.org/svn/asterisk/branches/1.8
        ........
        
        Merged revisions 378376 from http://svn.asterisk.org/svn/asterisk/branches/11
      ................
        r378384 | mjordan | 2013-01-02 16:19:32 -0600 (Wed, 02 Jan 2013) | 11 lines
        
        Clean up app_mysql's application entry points to properly parse arguments
        
        When parsing arguments, application entry points should not attempt to
        directly modify the parameters to the function. This patch properly duplicates
        the passed in parameters before attempting to parse them.
        
        (issue ASTERISK-20658)
        Reported by: wdoekes
        patches:
          issueA20658_sanitize_app_mysql.patch uploaded by wdoekes (license 5674)
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@378385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b375abae
    • Automerge script's avatar
      Merged revisions 378322 via svnmerge from · 675914bb
      Automerge script authored
      file:///srv/subversion/repos/asterisk/trunk
      
      ................
        r378322 | mjordan | 2013-01-02 12:11:59 -0600 (Wed, 02 Jan 2013) | 33 lines
        
        Prevent exhaustion of system resources through exploitation of event cache
        
        Asterisk maintains an internal cache for devices in the event subsystem. The
        device state cache holds the state of each device known to Asterisk, such that
        consumers of device state information can query for the last known state for
        a particular device, even if it is not part of an active call. The concept of
        a device in Asterisk can include entities that do not have a physical
        representation. One way that this occurred was when anonymous calls are allowed
        in Asterisk. A device was automatically created and stored in the cache for
        each anonymous call that occurred; this was possible in the SIP and IAX2
        channel drivers and through channel drivers that utilized the
        res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
        are never removed from the system, allowing anonymous calls to potentially
        exhaust a system's resources.
        
        This patch changes the event cache subsystem and device state management to
        no longer cache devices that are not associated with a physical entity.
        
        (issue ASTERISK-20175)
        Reported by: Russell Bryant, Leif Madsen, Joshua Colp
        Tested by: kmoore
        patches:
          event-cachability-3.diff uploaded by jcolp (license 5000)
        ........
        
        Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
        ........
        
        Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
        ........
        
        Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@378329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      675914bb
    • Automerge script's avatar
      Merged revisions 378288 via svnmerge from · 59663645
      Automerge script authored
      file:///srv/subversion/repos/asterisk/trunk
      
      ................
        r378288 | mjordan | 2013-01-02 09:39:42 -0600 (Wed, 02 Jan 2013) | 36 lines
        
        Resolve crashes due to large stack allocations when using TCP
        
        Asterisk had several places where messages received over various network
        transports may be copied in a single stack allocation. In the case of TCP,
        since multiple packets in a stream may be concatenated together, this can
        lead to large allocations that overflow the stack.
        
        This patch modifies those portions of Asterisk using TCP to either
        favor heap allocations or use an upper bound to ensure that the stack will not
        overflow:
         * For SIP, the allocation now has an upper limit
         * For HTTP, the allocation is now a heap allocation instead of a stack
           allocation
         * For XMPP (in res_jabber), the allocation has been eliminated since it was
           unnecesary.
        
        Note that the HTTP portion of this issue was independently found by Brandon
        Edwards of Exodus Intelligence.
        
        (issue ASTERISK-20658)
        Reported by: wdoekes, Brandon Edwards
        Tested by: mmichelson, wdoekes
        patches:
          ASTERISK-20658_res_jabber.c.patch uploaded by mmichelson (license 5049)
          issueA20658_http_postvars_use_malloc2.patch uploaded by wdoekes (license 5674)
          issueA20658_limit_sip_packet_size3.patch uploaded by wdoekes (license 5674)
        ........
        
        Merged revisions 378269 from http://svn.asterisk.org/svn/asterisk/branches/1.8
        ........
        
        Merged revisions 378286 from http://svn.asterisk.org/svn/asterisk/branches/10
        ........
        
        Merged revisions 378287 from http://svn.asterisk.org/svn/asterisk/branches/11
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@378296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      59663645
  2. Jan 01, 2013
  3. Dec 31, 2012
  4. Dec 20, 2012
  5. Dec 18, 2012
  6. Dec 17, 2012
  7. Dec 14, 2012
  8. Dec 13, 2012
  9. Dec 12, 2012
  10. Dec 11, 2012
  11. Dec 10, 2012
Loading