ASTERISK-25220 #close

Change-Id: Ic48f3a82f51ada87f2fb0e016c9efe0ad56f1ee3

When running valgrind on Asterisk, it complained about:

    ==32423== Source and destination overlap in memcpy(0x85a920, 0x85a920, 304)
    ==32423==    at 0x4C2F71C: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/...)
    ==32423==    by 0x55BA91: ast_rtp_engine_unload_format (rtp_engine.c:2292)
    ==32423==    by 0x4EEFB7: ast_format_attr_unreg_interface (format.c:1437)

The code in question is a struct assignment, which may be performed by
memcpy as a compiler optimization. It is changed to only copy the struct
contents if source and destination are different.

ASTERISK-25219 #close

Change-Id: I6d3546c326b03378ca8e9b8cefd41c16e0088b9a

If DEBUG_FD_LEAKS was used and more file descriptors than the default of
1024 were available, some DEBUG_FD_LEAKS-patched functions would
overwrite memory past the fixed-size (1024) fdleaks buffer.

This change:
- adds bounds checks to __ast_fdleak_fopen and __ast_fdleak_pipe
- consistently uses ARRAY_LEN() instead of sizeof() or 1023 or 1024
- stores pointers to constants instead of copying the contents
- reorders the fdleaks struct for possibly tighter packing
- adds a tiny bit of documentation

ASTERISK-25212 #close

Change-Id: Iacb69e7701c0f0a113786bd946cea5b6335a85e5

This fixes so a failure to get a timer file descriptor does not cascade
to closing FD 0.

On error, both res_timing_kqueue and res_timing_timerfd would call the
destructor before setting the file handle. The file handle had been
initialized to 0, causing FD 0 to be closed. This in turn, resulted in
floods of "CLI>" messages and an unusable terminal.

ASTERISK-19277 #close
Reported by: Barry Chern

Change-Id: I147d7e33726c6e5a2751928d56561494f5800350

Change-Id: I0ec7fd10d56d90d5a60b12b5a7d6807f265ac5e0

When a frame is queued on a channel, any failure in
ast_channel_alert_write is logged along with errno.

This change improves the diagnostic message through
aligning the errno value with actual failure cases.

ASTERISK-25224
Reported by: Andrey Biglari

Change-Id: I1bf7b3337ad392789a9f02c650589cd065d20b5b

This patch updates a variety of Makefiles in Asterisk's build system to
remove .gcda and .gcno files when 'make clean' is executed. These files
are generated when '--enable-coverage' is passed to the Asterisk
configure script.

Change-Id: Ib70b41eea2ee2908885bff02e80faf9f40c84602

When 8297136f was merged for ASTERISK-25040, a regression was introduced
surrounding the case sensitivity of device names within hints.
Previously, device names - such as 'sip/foo' - were compared in a case
insensitive fashion. Thus, 'sip/foo' was equivalent to 'SIP/foo'. After
that patch, only the case sensitive name would match, i.e., 'SIP/foo'.
As a result, some dialplan hints stopped working.

This patch re-introduces case insensitive matching for device names in
hints.

ASTERISK-25040

ASTERISK-25202 #close

Change-Id: If5046a7d14097e1e3c12b63092b9584bb1e9cb4c

If a client sends and INVITE which is 401 rejected, then subsequently
sends a new INVITE with the auth info and uses a different fromtag
from the first INVITE, Asterisk will accept the new INVITE as part of
the original dialog - match_req_to_dialog() specifically ignores the
fromtag. However it does not update the stored dialog with the new
fromtag.

This results in Asterisk being unable to match future packets that are
part of this dialog (such as the ACK to the OK or the OK to the BYE),
and the call is dropped.

This problem was originally found when using an NEC-i SV8100-GE (NEC SIP
Card).

* After a successful match of a packet to the dialog, if the packet is
  not a SIP_RESPONSE, authentication is present and the fromtags are
  different, the stored fromtag is updated with the one from the recent
  INVITE.

ASTERISK-25154 #close
Reported by: Damian Ivereigh
Tested by: Damian Ivereigh

Change-Id: I5c16cf3b409e5ef9f2b2fe974b6bd2a45a6aa17e

When a BYE with an Also header is successfully processed, and the sender
of the BYE is bridged with another channel, chan_sip will unlock the
owner of the dialog on which the BYE was received, call ast_async_goto()
on the bridged channel, and then re-lock the owner. The reason for this
locking behavior is that ast_async_goto() can result in a masquerade,
which requires that the involved channels are unlocked.

The problem here is that this causes a locking inversion since the
dialog's lock is held when re-locking the owner channel after the async
goto. The lock order is supposed to be channel and then sip_pvt.

The fix proposed is simple. In addition to unlocking the owner channel
before the ast_async_goto() call, also unlock the sip_pvt. Then relock
both after ast_async_goto() returns, being sure to lock the channel and
then the sip_pvt.

ASTERISK-25139 #close
Reported by Gregory Massel

Change-Id: I72c4fc295ec8573bee599e8e9213c5350a3cd224

Although ast_context_find, ast_context_find_or_create and
ast_context_destroy perform locking of the contexts table,
any context pointer can become invalid at any time that the
contexts table is unlocked. This change adds locking around
all complete operations involving these functions.

Places where ast_context_find was followed by ast_context_destroy
have been replaced with calls ast_context_destroy_by_name.

ASTERISK-25094 #close
Reported by: Corey Farrell

Change-Id: I1866b6787730c9c4f3f836b6133ffe9c820734fa

Show uptime information ends with an unnecessary space.

Now NEEDCOMMA is better defined.

Change-Id: I11b360504a0703309ff51772ff8f672287f3c5a1

GCC 4.7 Manual:
http://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Function-Attributes.html

weakref ("target")

A weak reference is an alias that does not by itself require a definition
to be given for the target symbol.

ASTERISK-22559 #close
Reported by: Ibercom

Change-Id: I36a136cae947b65187a697533416f9ff9a0b8cdf

The length of frames retured by sample functions was twice as large as
real, what caused global buffer overflow caught by AddressSanitizer.

ASTERISK-24717 #close
Reported by: Badalian Vyacheslav

Change-Id: Iec2fe682aef13e556684912f906bedf7c18229c6

The code in astobj2_hash.c wrongly assumed that abs(int) is always > 0.
However, abs(INT_MIN) = INT_MIN and is still negative, as well as
abs(INT_MIN) % num_buckets, and as a result this led to a crash.

One way to trigger the bug is using host=::80 or 0.0.0.128 in peer
configuration section in chan_sip or chan_iax.

This patch takes the remainder before applying abs, so that bucket
number is always in range.

ASTERISK-25100 #close
Reported by: Mark Petersen

Change-Id: Id6981400ad526f47e10bcf7b847b62bd2785e899

Reset options to default values before reloading config.  This ensures
that if a setting is removed or commented out of the configuration file
it is unset on reload.

ASTERISK-25112 #close
Reported by: Corey Farrell

Change-Id: Id24bb1fb0885c2c14cf8bd6f69a0c2ee7cd6c5bd

ASTERISK-24887 #close
Reported by: Makoto Dei
Tested by: tensai

Change-Id: I6a96f572adb17f76b3acafe503a01c48eb5dd9bf

Currently, everytime a sample rate change occurs (on read or write) the
associated factory buffers are reset. If the requested sample rate on a
read differed from that of a write then the buffers are continually reset
on every read and write. This has the side effect of emptying the buffer,
thus there being no data to read and then write to a file in the case of
call recording.

This patch fixes it so that an audiohook_list's rate always maintains the
maximum sample rate among hooks and formats. Audiohook sample rates are
only overwritten by this value when slin native compatibility is turned on.
Also, the audiohook sample rate can only overwrite the list's sample rate
when its rate is greater than that of the list or if compatibility is
turned off. This keeps the rate from constantly switching/resetting.

ASTERISK-24944 #close
Reported by: Ronald Raikes

Change-Id: Idab4dfef068a7922c09cc631dda27bc920a6c76f

The message channel is a special channel that doesn't actually process frames.
However, certain actions can cause frames to be placed in the channel's read
queue including the Hangup application which is called on the channel after
each message is processed. Since the channel will continually be reused for
many messages, it's necessary to flush these frames at some point.

ASTERISK-25083 #close
Reported by: Jonathan Rose

Change-Id: Idf18df73ccd8c220be38743335b5c79c2a4c0d0f

Fix the alphabetic order added on ast_manager_register_struct. The order
for struct manager_action added is not working, this change fixes the
problem.

Change-Id: I149da0cd06c3c4445d7516cc303358e9f26f8b4b

MySQL configuration engine contains a bug in require_mysql(). This
function is used for column type checking in tables. This bug only
affects DATETIME, DATE and FLOAT types.

It came from mixing the first condition (switch-case-like
if/then/else), to check the expected column type, with the second
condition, to check the actual column type against the expected column
type. Both conditions must be checked separately in order to avoid the
execution of the wrong block.

ASTERISK-18252 #comment This patch might fix the issue
Reported by: Gareth Blades

ASTERISK-25041 #close
Reported by: Alexandre Fournier
Tested by: Alexandre Fournier

Change-Id: I0b8bf7e68ab938be8e6525a249260cb648cb0bfa

First byte of DTLS packet shall be in range 20-63, not 20-64. Refer to RFC
https://tools.ietf.org/html/rfc5764#section-5.1.2 for correct values.

Change-Id: Iae6fa0d72b37c36a27fe40686e0ae6fba3afec31

If an ISDN call is hungup by both sides at the same time a crash could
happen.

* Added missing NULL checks for the owner channel after calling
pri_queue_pvt_cause_data() in two places.  Code after those calls need to
check the owner channel pointer for NULL before use because
pri_queue_pvt_cause_data() needs to do deadlock avoidance to lock the
owner and the owner may get hung up.

ASTERISK-21893 #close
Reported by:  Alexandr Gordeev

Change-Id: Ica3e266ebc7a894b41d762326f08653e1904bb9a

MAKE_MENUSELECT currently sets CC to CC, which is the compiler for the
target platform. But menuselect is to be run on the build system, so
BUILD_CC needs to be used instead - like it was in the past, before the
recent changes (https://reviewboard.asterisk.org/r/4370/). This is the
patch for ASTERISK-25074.

ASTERISK-25074 #close
Reported by: Sebastian Kemper
Tested by: Sebastian Kemper

Change-Id: I8a2b1fc5deb6ad2b80f49baca35b1b13d468ebf8

The code which reads asterisk.conf supports processing the debug
option with ast_true, but ast_true returns -1.  This causes debug
to still be off, convert to 1 so debug will be on as requested.

ASTERISK-25042
Reported by: Corey Farrell

Change-Id: I3c898b7d082d914b057e111b9357fde46bad9ed6