If the global_curl_info data structure could not be allocated, the
datastore associated with the operation would be free'd, but the function
would not return. This would later dereference the datastore, almost
certainly causing Asterisk to crash. With this patch, if the data
structure is not allocated the method will return an error code, and
not attempt any further operation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361753 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the MWI processing loop, when a valid event occurs the temporary caller ID
information is deallocated. If a new DAHDI channel is successfully created,
the event is passed up to the analog_ss_thread without error and the loop
exits. If, however, the DAHDI channel is not created, then the caller ID
struct has been free'd, and the gains reset to their previous level. This
will almost certainly cause an invalid access to the free'd memory, either
in subsequent calls to callerid_free or calls to callerid_feed.
This patch makes it so that we only free the caller ID structure if a
DAHDI channel is successfully created, and we bump the gains back up
if we fail to make a DAHDI channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the SHARED function modifies a variable, it removes it from its list of
variables and reinserts the new value at the head of the list of variables.
Doing this inside a standard list traversal can be dangerous, as the
standard list traversal does not account for the list being changed. While
the code in question should not cause a use after free violation due to its
breaking out of the loop after freeing the variable, it could lead to a
maintenance issue if the loop was modified. This also fixes a violation
reported by a static analysis tool, which also makes this code easier to
maintain in the future.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361657 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the XML calendar data returned by a Microsoft Exchange Web Service
specifies an XML Event E-Mail Address ("EmailAddress"), and no e-mail address
is provided, a condition existed where an ast_calendar_attendee struct would
be allocated but not appended to the list of attendees. Because of that,
the memory associated with the attendee would never be freed. This patch
frees the memory if no e-mail address is provided.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A memory leak/reference counting leak occurs if the MeetMeAdmin 'e' command
(eject last user that joined) is used in conjunction with a specified user.
Regardless of the command being executed, if a user is specified for the
command, MeetMeAdmin will look up that user. Because the 'e' option kicks
the last user that joined, as opposed to the one specified, the reference to
the user specified by the command would be leaked when the user variable
was assigned to the last user that joined.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361558 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a '\n' to the warning messages when we ignore a media stream due to the
port number being '0'.
(closes issue ASTERISK-19646)
Reported by: Badalian Vyacheslav
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The error message for failure to stop autoservice after a gosub or macro call
during a dial was removed for macro while Asterisk 1.4 was still being actively
developed. The corresponding gosub error message was never removed.
(closes issue ASTERISK-19551)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The important parts of the patch were already applied through other updates.
(closes issue ASTERISK-19445)
Reported by: Makoto Dei
Patches:
memset-memcpy-length.patch uploaded by Makoto Dei (license 5027)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This came up while fixing documentation generation for many other cases where
the argument separator was not being displayed properly. Now that it is
displayed properly, it shows up in the wrong place for Transfer since the '/'
is only required if Tech is present.
(related to issue ASTERISK-18168)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@361040 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change prevents Asterisk from sending RTCP receiver reports during a
remote bridge since it is no longer receiving media and should not be
reporting anything.
(related to ASTERISK-19366)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360987 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The logger_thread() had an exit path that failed to release the logmsgs
list lock.
* Make logger_thread() exit path unlock the logmsgs list lock.
* Made ast_log() not queue any messages to the logmsgs list if the
close_logger_thread flag is set.
(issue ASTERISK-19463)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, a connected line update was queued during
call pickup and then an answer frame was queued. The original
caller would presumably then have his connected line updated
and then the call would be answered.
In actuality, the answer frame was not how the call ended up
being answered. Rather, an odd section in app_dial that checks
if the called channel's state is up.
The result is that the order of the connected line update and
the answer were variable. In most cases, this wasn't actually
a bad thing. However, if the 'I' option was passed to dial, the
connected line update would be inhibited.
The fix is to queued the connected line after the answer frame is
queued. This way the race in app_dial is between two
conditions resulting in an answer. This way the connected line
update occurs after the answer every time.
(closes issue ASTERISK-19183)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Mark Michelson
Patches:
ASTERISK-19183.patch uploaded by Mark Michelson (license 5049)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes use of connected party information in addition to caller ID in order
to populate local and remote XML elements in the dialog-info NOTIFYs.
(closes issue ASTERISK-16735)
Reported by: Maciej Krajewski
Tested by: Maciej Krajewski
Patches:
local_remote_hint2.diff uploaded by Mark Michelson (license 5049)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360862 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I was getting confused during some testing why Asterisk was saying that
a subscription was being added when it was clearly being removed. This
fixes that confusion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While this does not fix the issue of the CLI being flooded by 'doing
dnsmgr_lookup' messages, increasing the verbosity level above 5 should help
minimize it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dial_list is a dynamically allocated array that is allocated at the beginning
of Page() based on how many devices will be dialed. This was never being freed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is needed to include the last fix to main/ast_expr2.y. The changes look
much bigger as this regeneration of the code was done with newer versions of
flex and bison.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix a memory leak that is very unlikely to actually happen. If a malloc()
succeeded, but the following strdup() failed, the memory from the original
malloc() would be leaked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Q.951 indicates that when the presentation indicator is "Number not
available due to interworking" for a number then the screening indicator
field should be "Network provided".
* Made ast_party_id_presentation() return AST_PRES_NUMBER_NOT_AVAILABLE
when the presentation is "Number not available due to interworking". This
fix makes Asterisk consistent and it also makes it consistent with earlier
branches as far as this presentation value is concerned.
* Made pri_to_ast_presentation() and ast_to_pri_presentation() conversions
handle the "Number not available due to interworking" case better in
sig_pri.c. This change is possible because the minimum required libpri
version (v1.4.11) has the necessary defines in libpri.h.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk detects a hangup and cannot send a BYE due to a pending
INVITE, it sets the pendingbye flag and waits for the final response to that
INVITE. When the response is received, it transmits the BYE. If, however,
that INVITE request is a pending re-INVITE, it needs to first send a CANCEL
request to terminate the pending re-INVITE. In that circumstance, Asterisk
was, in some scenarios, clearing the pendingbye flag after processing the
CANCEL request and not checking for a pending BYE when receiving the final
487 response to the INVITE.
This patch ensures that if the pendingbye flag is set, it is honored
regardless of the nature of the INVITE request currently in flight.
(closes issue ASTERISK-19365)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches:
bugASTERISK-19365_2012_03_08.patch uploaded by mjordan (license 6283)
Review: https://reviewboard.asterisk.org/r/1807
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360086 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Echo()'s description states that it echoes audio, video, and DTMF except for #
while it actually echoes any frame that it receives other than DTMF #. This
was causing frame storms in the test suite in some circumstances where Echo()
was attached to both ends of a pair of local channels and control frames
were being periodically generated. Echo()'s behavior and description have
been modifed so that it only echoes media and non-# DTMF frames.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@360033 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359979 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a bug with chanspy on local channels which roughly 50% of the time
would create a situation where chanspy can latch onto a zombie channel, keeping the zombie
alive forever and causing the channel doing the spying to never be able to hang up.
(closes issue ASTERISK-19493)
Reported by: lvl
Review: https://reviewboard.asterisk.org/r/1819/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359706 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The connected line interception macros do not get executed when the
outgoing channel is initially created and that channel's caller-id is
implicitly imported into the incoming channel's connected line data. If
you are using the interception macros, you would expect that they get run
for every change to a channel's connected line information outside of
normal dialplan execution.
Review: https://reviewboard.asterisk.org/r/1817/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Initialize a struct sockaddr_in in try_transfer() so that the code isn't
(potentially) trying to read from it while uninitialized.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359558 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ensure that status is set before it is used by resetting it during each loop
iteration. This could have resulted in incorrect results from this app.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Scan results indicated that this array could be used uninitialized. At a quick
look, it looks correct. In any case, initializing it is a Good Thing (tm).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@359457 65c4cc65-6c06-0410-ace0-fbb531ad65f3
