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.
(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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@359615 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revert part of r315643. We need to remove the datastore here as well.
The code in bridging code will catch anything that app_dial might miss.
(closes issue #19311)
Reported by: mspuhler
Patches:
issue_19311_no_answer.diff uploaded by elguero (license 37)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@319527 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
* The applicable fixes for v1.4 are the SIP deadlock and the in progress
masquerade check for multiple parties trying to pickup the same call.
issue18654_v1.4.patch uploaded by rmudgett (license 664)
* Backported to v1.6.2.
issue18654_v1.6.2.patch uploaded by rmudgett (license 664)
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@318734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This part of the change for r315596 was incorrect. No bridge occurs
when doing a roundrobin dial and no one answers, so this code shouldn't
have been removed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@317574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We try to avoid the situation where two phones may be forwarded to each other
causing an infinite loop by storing each dialed interface in a channel
datastore and checking the list before dialing out. This works, but currently
breaks situations like A calls B, A transfers B to C, B transfers C to A, and A
transfers C to B. Since human interaction is happening here and not an
automated forwarding loop, it should be allowed.
This patch removes the dialed_interfaces datastore when a call is bridged (a
suggestion from the brilliant mmichelson). If a call is being bridged, it
should be safe to assume that we aren't stuck in a loop.
Since we are now handling this is the bridge code, the previous attempts at
handling it in app_dial and app_queue are removed.
Review: https://reviewboard.asterisk.org/r/1195/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@315596 65c4cc65-6c06-0410-ace0-fbb531ad65f3
trivial change to bring inline with 1.6.2 1.8 and trunk.
The symptom was if msg0000 was missing, and the last was msg0004,
the next msgnum would be msg0000 when it should have been msg0005
(issue #18998)
Reported by: tootai
Patches:
bug18998.diff2.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@312290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
change last_message_index to read the max msgnum stored in the database
change count_messages to actually count the number of messages.
last_message_index change:
This fixed overwriting of the last message if msgnum=0 was missing.
Previously every incoming message would overwrite msgnum=1.
count_messages change:
allows us to detect when requencing is required in opneA_mailbox.
resequence enabled for ODBC storage:
Assists with fixing up corrupt databases with gaps, but only when
a user actively opens there mailboxes.
(closes issue #18692,#18582,#19032)
Reported by: elguero
Patches:
based on odbc_resequence_mailbox2.1.diff uploaded by elguero (license 37)
Tested by: elguero, nivek, alecdavis
Review: https://reviewboard.asterisk.org/r/1153/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@312174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
close_mailbox leave gaps in message sequence if messages are deleted and new messages
arrive during this time, this is because the shuffle down to slot 0, only shuffles
the number of pre-existing messages when mailbox is opened, ignoring new arrivals.
Fix: in close_mailbox re-evaluate number of messages before the shuffle, this then includes new arrivals.
Happens on filebased or ODBC storage.
(issues #19032,#18582,#18692,#18998)
Reported by: alecdavis,tootai,afosorio
Review: https://reviewboard.asterisk.org/r/1153/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@312070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This reverts r298596, which was to fix a highly bizarre and contrived issue
with a queue member that called into his own queue being transferred back
into his own queue. I couldn't reproduce that issue in any way. I think one
of the other recent transfer fixes actually fixed this.
(closes issue #18747)
Reported by: vrban
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@308002 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The message duration is stored in the body of the email when using IMAP_STORAGE,
so nothing needs to happen with the backup file.
(closes issue #18718)
Reported by: kerframil
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@306960 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Include the null terminator in the buffer length. When the frame is
queued it is copied. If the null terminator is not part of the frame
buffer length, the receiver could see garbage appended onto it.
* Add channel lock protection with ast_sendtext().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@305888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_iax2 and other channel drivers already had code to prevent this. The
attempt that app_dial was making to prevent it was not correct, so I fixed that.
(closes issue #18371)
Reported by: gbour
Patches:
18371.patch uploaded by gbour (license 1162)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@305252 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A previous change was made to account for when the number of voicemail messages
exceeds the max limit to be handled properly, but it caused gaps in the messages
to not be properly handled. This has now been resolved.
In later non 1.4 branches, it appears that resequencing wasn't even occurring
due from what appears and accidental code removal.
(closes issue #18498)
Reported by: JJCinAZ
Patches:
bug18498v2.patch uploaded by jpeeler (license 325)
(closes issue #18486)
Reported by: bluefox
Patches:
bug18486.patch uploaded by jpeeler (license 325)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@303676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
working properly. This issue includes a patch that resolves the issue by
removing a call to ast_check_hangup() from app_meetme.c. I left that in my
patch, as it doesn't need to be there. However, the rest of the patch fixes
this problem with or without the change to app_meetme.
The key difference between what happens before and after this patch is the
effect of the END_OF_Q control frame. After END_OF_Q is hit in ast_read(),
ast_read() will return NULL. With the ast_check_hangup() removed, app_meetme
sees this which causes it to exit as intended. Checking ast_check_hangup()
caused app_meetme to exit earlier in the process, and the target of the
redirect saw the condition where ast_read() returned NULL.
Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
solve the issue if another application did the same thing. There are also
other edge cases where if an application finishes at the same time that a
redirect happens, the target of the redirect will think that the channel hung
up. So, I made some changes in pbx.c to resolve it at a deeper level. There
are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
abort the hangup process. My patch extends this to remove the END_OF_Q frame
from the channel's read queue, making the "abort hangup" more complete. This
same technique was used in every place where a softhangup flag was cleared.
(closes issue #18585)
Reported by: oej
Tested by: oej, wedhorn, russell
Review: https://reviewboard.asterisk.org/r/1082/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@303546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change the verbose output of option L() to say milliseconds and not seconds
as the value is in milliseconds.
(closes issue #18264)
Reported by: jacco
Patches:
app_dial_patch.txt uploaded by lmadsen (license 10)
Tested by: lmadsen, jacco
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@302916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically in the case of timing out but not leaving voicemail nothing
should be heard. And when leaving voicemail it should be heard.
ABE-2647
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@300918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Had to indicate ringing in wait_for_answer so the attended transfer code would
not try and hang up the local channel it created, which would kill the call.
ABE-2624
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@298596 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #18126)
Reported by: junky
Patches:
followme.diff uploaded by junky (license 177)
(partially restructured by me to avoid a possible memory leak)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@297689 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is in response to some questions on IRC. To the user, there was nothing
that made it obvious that this error had anything to do with DAHDI not being
loaded.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@297228 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem scenario occurred on a heavily loaded system that was using the
codec_dahdi module and exceeded the hardware transcoding capacity. The failure
mode at that point was not good. The report came in to us as an Asterisk
lock-up. The "core show locks" shows a ton of threads locked up (but no
obvious deadlock). Upon deeper investigation, when the system is in this
state, the CPU was maxed out. The CPU was being consumed by the Asterisk
logger spewing messages on every audio frame for calls set up after transcoder
capacity was reached.
The purpose of this patch is to make Asterisk handle failures to create a
translation path in a more graceful manner. If we can't translate, then the
call just needs to be dropped, as it's not going to work. These are the
changes:
1) In set_format() of channel.c (which is called by set_read_format() and
set_write_format()), it was ignoring if ast_translator_build_path() failed and
returned NULL. It now pays attention to that case and returns a result
reflecting failure. With this change in place, the bridging code will
immediately detect a failure and end the bridge instead of proceeding to try to
bridge frames that can't be translated and making channel drivers freak out by
sending them frames in a format they weren't expecting.
2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
ignored. It is now reflected in the return value of the function. This didn't
turn out to have any affect on the bug, but seemed like a good change to leave
in.
3) In app_dial(), when only sending a call to a single endpoint, it will
attempt to do some bridging of its own of early audio. It uses
make_compatible() when it's going to do this. However, it ignored failure from
make compatible. So, even with the fix from #1, if there was early audio going
through app_dial, there would still be a period of invalid frames passing
through. After detecting failure here, Dial() exits.
ABE-2658
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@296000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.
Note that if the CLI command were done on the channel call leg associated
with B it works.
This regression was a result of the fix for issue #16946
(https://reviewboard.asterisk.org/r/740/).
The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.
The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.
The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.
JIRA SWP-2470
JIRA SWP-2489
(closes issue #18171)
Reported by: SantaFox
(closes issue #18185)
Reported by: kwemheuer
(closes issue #18211)
Reported by: zahir_koradia
(closes issue #18230)
Reported by: vmarrone
(closes issue #18299)
Reported by: mbrevda
(closes issue #18322)
Reported by: nerbos
Review: https://reviewboard.asterisk.org/r/1013/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@295790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It seems the fix to issue 17103 was a little overzealous and removed the code
that backed up the textfile containing the original message duration. This
code has now been restored.
(related to issue #17103)
ABE-2654
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@295200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to be more safe, some error handling code was changed to respect more
error conditions including the potential memory allocation failure for deleted
and heard message tracking introduced in 293004. However, last_message_index
returns -1 for zero messages (perhaps as expected) and was triggering the
stricter error checking. Because last_message_index is only called directly
in one place, just return 0 from open_mailbox (for file based storage) when no
messages are detected unless a real error has occurred.
(closes issue #18240)
Reported by: leobrown
Patches:
bug18240.1-6-2.diff.txt uploaded by alecdavis (license 585)
Tested by: pabelanger
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@294903 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The comparison function logic was off, so the number of sessions for a given
mailbox were not being incremented properly. This problem caused the maximum
number of messages per folder to not be respected when simultaneously leaving
multiple voicemails just below the threshold.
These problems should be fixed by the above, but just in case:
Fixed resequence_mailbox to rely on the actual number of detected number of
files in a directory rather than just assuming only 10 messages more than the
maximum had been left. Also if more messages than the maximum are deleted they
are actually removed now.
The second purpose of this commit should have been separated out probably, but
is related to the above. Again, if the number of messages in a given voicemail
folder exceeds the maximum set limit make sure to allocate enough space for the
deleted and heard index tracking array.
A few random fixes:
There was a forgotten decrement of the inprocess count in imap_store_file.
When using IMAP storage, do not look in the directory where file based storage
messages may still reside and influence the message count.
Ensure to use only the first format in sendmail.
ABE-2516
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@293004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a fix for when pressing the operator key after recording an unavailable,
busy, name, or temporary message in mailbox options. The operator key should not
be accepted here, but should be allowed during the message recording. If the
operator key is pressed during ensure the file is saved or deleted as
apporopriate. Also, ensure removal of temporary recorded files after an early
hang up or when message acceptance confirmation times out.
ABE-2518
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@292223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since the data being passed to the generator callback is on the stack of the
SMS() application, we must ensure that the generator is stopped before the
application exits.
ABE-2587
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@289424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the 'a' MeetMe flag and having a user and admin pin setup for your
conference, using the user pin would gain you admin priviledges. Also, when no
user pin was set, an admin pin was, the 'a' MeetMe flag wasn't used, and the
user tried to enter a conference then they were still prompted for a pin and
forced to hit #.
(closes issue #17908)
Reported by: kuj
Patches:
pins_2.patch uploaded by kuj (license 1111)
Tested by: kuj
Review: [full review board URL with trailing slash]
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@287758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically, before prompting to record a prepended message the capacity is
checked first. If the mailbox is full the extension will be reprompted.
ABE-2517
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@286941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matthew Jordan
Richard Mudgett
Terry Wilson
Sean Bright
Alec L Davis
Tilghman Lesher
Jonathan Rose
David Ruggles
Jason Parker
Jeff Peeler
Russell Bryant
Leif Madsen
Tzafrir Cohen
Paul Belanger
Brett Bryant