A very inappropriate placement of a ')' (introduced in r362151) caused the
maximum size of a file to be set as the result of a comparison operation, as
opposed to the result of the ftello operation. This resulted in seeking being
restricted to the beginning of the file, or 1 byte into the file. Thanks to
the Asterisk Test Suite for properly freaking out about this on at least one
test.
(issue ASTERISK-19655)
Reported by: Matt Jordan
........
Merged revisions 362304 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362305 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a bind address is set to an ANY address (udpbindport=::), a warning message
is displayed stating that "Address remapping activated in sip.conf but we're
using IPv6, which doesn't need it. Please remove 'localnet' and/or 'externaddr'
settings." But if one is running dual stack, we shouldn't be told to turn those
settings off.
This patch checks if the bind address is an ANY address or not. The warning
message will now only be displayed if the bind address is NOT an ANY address and
IPv6 is being used.
Also, updated the copyright year.
(closes issue ASTERISK-19456)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
chan_sip_ipv6_message.diff uploaded by Michael L. Young (license 5026)
........
Merged revisions 362253 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362264 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In chan_agent, while handling a channel indicate, the agent channel driver
must obtain a lock on both the agent channel, as well as the channel the
agent channel is using. To do so, it attempts to lock the other channel
first, then unlock the agent channel which is locked prior to entry into
the indicate handler. If this unlock fails with a negative return value,
which can occur if the object passed to agent_indicate is an invalid ao2
object or is NULL, the return value is passed directly to strerror, which
can only accept positive integer values.
In chan_dahdi, the return value of dahdi_get_index is used to directly
index into the sub-channel array. If dahd_get_index returns a negative
value, it would use that value to index into the array, which could cause
an invalid memory access. If dahdi_get_index returns a negative number,
we now default to SUB_REAL.
(issue ASTERISK-19655)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1863/
........
Merged revisions 362204 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362205 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When storing a voicemail message using an ODBC connection to a database, the
voicemail message is first stored on disk. The sound file associated with
the message is read into memory before being transmitted to the database.
When this occurs, a failure in the C library's lseek function would cause a
negative value to be passed to the mmap as the size of the memory map to
create. This would almost certainly cause the creation of the memory map to
fail, resulting in the message being lost.
(issue ASTERISK-19655)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1863
........
Merged revisions 362201 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362202 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The current Security Events Framework API only supports IPv4 when it comes to
generating security events. This patch does the following:
* Changes the Security Events Framework API to support IPV6 and updates
the components that use this API.
* Eliminates an error message that was being generated since the current
implementation was treating an IPv6 socket address as if it was IPv4.
* Some copyright dates were updated on files touched by this patch.
(closes issue ASTERISK-19447)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
security_events_ipv6v3.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/1777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For the formats that support seek and/or truncate operations, many of
the C library calls used to determine or set the current position indicator
in the file stream were not being checked. In some situations, if an error
occurred, a negative value would be returned from the library call. This
could then be interpreted inappropriately as positional data.
This patch checks the return values from these library calls before
using them in subsequent operations.
(issue ASTERISK-19655)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1863/
........
Merged revisions 362151 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362152 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, ForkCDR's e option would immediately set the end time of the forked
CDR to that of the CDR that is being terminated. This resulted in the new CDR's end time
being roughly the same as it's beginning time (which is in turn roughly the same as the
original's end time).
(closes issue ASTERISK-19164)
Reported by: Steve Davies
Patches:
cdr_fork_end.v10.patch uploaded by Steve Davies (license 5012)
........
Merged revisions 362082 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362084 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTERISK-18809 eliminated the legacy macro invocation of the stdexten in
favor of the Gosub method without a means of backwards compatibility.
(issue ASTERISK-18809)
(closes issue ASTERISK-19457)
Reported by: Matt Jordan
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1855/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361998 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.
* Rework the -r361705 patch to better manage the cs and mtd allocated
resources.
* Fixed use of mwimonitoractive flag to be correct if the mwi_thread()
fails to start.
........
Merged revisions 361854 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361855 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361856 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
........
Merged revisions 361753 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361754 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361755 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.
........
Merged revisions 361705 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361706 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361707 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.
........
Merged revisions 361657 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361658 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361659 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.
........
Merged revisions 361606 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361607 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361608 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.
........
Merged revisions 361558 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361560 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Doing Set(MESSAGE_DATA(key)=) would add an empty key header if the key
header did not already exist. If it already existed it would delete it.
* Made msg_set_var_full() exit early if the named variable did not already
exist and the value to set is empty.
........
Merged revisions 361522 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Hangup now can take a regular expression as the Channel option. If you want
to hangup multiple channels, use /regex/ as the Channel option. Existing
behavior to hanging up a single channel is unchanged, but if you pass a regex,
the manager will send you a list of channels back that were hung up.
(closes issue ASTERISK-19575)
Reported by: Mark Murawski
Tested by: Mark Murawski
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361038 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)
........
Merged revisions 360884 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360885 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360886 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)
........
Merged revisions 360862 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360863 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Rename astobj2 API parameter funcname to func.
* Rename astobj2 API iterator parameter to iter.
* Update some documentation for OBJ_MULTIPLE.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Global ao2 objects must always exist after initialization because there is
no access control to obtain another reference to the global object.
It is expected that module configuration could use these new API calls to
replace an active configuration parameter object with an updated
configuration parameter object.
With these new API calls, the global object could be replaced, removed, or
referenced without the risk of someone using a stale global object
pointer.
Review: https://reviewboard.asterisk.org/r/1824/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Rather then flood the CLI with verbose messages, we've changed the level to
debug. This will help keep the CLI clean.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360536 65c4cc65-6c06-0410-ace0-fbb531ad65f3