[asterisk-bugs] [JIRA] (ASTERISK-18697) [minivm] Crash in MinivmNotify

Matt Jordan (JIRA) noreply at issues.asterisk.org
Wed Jan 30 13:50:30 CST 2013


     [ https://issues.asterisk.org/jira/browse/ASTERISK-18697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-18697:
-----------------------------------

    Target Release Version/s: 11.3.0
    
> [minivm] Crash in MinivmNotify
> ------------------------------
>
>                 Key: ASTERISK-18697
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-18697
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_minivm
>    Affects Versions: 1.8.7.0
>         Environment: Linux x86-64
>            Reporter: Chris Boot
>      Target Release: 1.8.21.0, 11.3.0
>
>         Attachments: minivm-null-pointer-dereference-fix.patch
>
>
> MinivmNotify() would reliably crash for me every time I called it. The backtrace is as follows:
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7f03dd355700 (LWP 3167)]
> 0x000000000052ba43 in __ast_str_helper (buf=0x7f03dd34f3d0, max_len=0, append=1, fmt=0x7f03e1a16c08 "%s%s?=%s", ap=0x7f03dd349b80) at strings.c:60
> 60              int offset = (append && (*buf)->__AST_STR_LEN) ? (*buf)->__AST_STR_USED : 0;
> (gdb) bt
> #0  0x000000000052ba43 in __ast_str_helper (buf=0x7f03dd34f3d0, max_len=0, append=1, fmt=0x7f03e1a16c08 "%s%s?=%s", ap=0x7f03dd349b80) at strings.c:60
> #1  0x000000000053beb9 in ast_str_append_va (buf=0x7f03dd34f3d0, max_len=0, fmt=<value optimized out>) at /home/bootc/asterisk-1.8/include/asterisk/strings.h:787
> #2  ast_str_append (buf=0x7f03dd34f3d0, max_len=0, fmt=<value optimized out>) at /home/bootc/asterisk-1.8/include/asterisk/strings.h:859
> #3  0x00007f03e1a0bdc3 in ast_str_encode_mime (end=<value optimized out>, maxlen=<value optimized out>, charset=<value optimized out>, start=<value optimized out>, preamble=9, postamble=<value optimized out>) at app_minivm.c:1188
> #4  0x00007f03e1a12278 in sendmail (template=<value optimized out>, vmu=0x2934030, cidnum=<value optimized out>, cidname=<value optimized out>, filename=<value optimized out>, format=<value optimized out>, duration=<value optimized out>, attach_user_voicemail=1,
>     type=MVM_MESSAGE_EMAIL, counter=0x0) at app_minivm.c:1416
> #5  0x00007f03e1a16142 in notify_new_message (chan=0x7f03d802bb38, templatename=<value optimized out>, vmu=0x2934030, filename=<value optimized out>, duration=<value optimized out>, format=<value optimized out>, cidnum=0x7f03d807f600 "07588833202",
>     cidname=0x7f03d802c420 "07588833202") at app_minivm.c:1810
> #6  0x00007f03e1a16a37 in minivm_notify_exec (chan=0x7f03d802bb38, data=<value optimized out>) at app_minivm.c:2139
> #7  0x00000000004eef0b in pbx_exec (c=0x7f03d802bb38, app=0x2916e40, data=0x7f03dd352780 "bootc at bootc.net") at pbx.c:1421
> #8  0x00000000004fbd0a in pbx_extension_helper (c=0x7f03d802bb38, con=<value optimized out>, context=0x7f03d802c090 "minivm_cleanup", exten=0x7f03d802c0e0 "~~s~~", priority=<value optimized out>, label=<value optimized out>, callerid=0x7f03d807f600 "07588833202",
>     action=E_SPAWN, found=0x7f03dd354dfc, combined_find_spawn=1) at pbx.c:4119
> #9  0x0000000000501d3e in ast_spawn_extension (c=0x7f03d802bb38, args=<value optimized out>) at pbx.c:4744
> #10 __ast_pbx_run (c=0x7f03d802bb38, args=<value optimized out>) at pbx.c:5068
> #11 0x0000000000502009 in pbx_thread (data=0x7f03dd34f3d0) at pbx.c:5177
> #12 0x000000000053ad1a in dummy_start (data=<value optimized out>) at utils.c:1004
> #13 0x00007f03e67d78ba in start_thread () from /lib/libpthread.so.0
> #14 0x00007f03e701002d in clone () from /lib/libc.so.6
> #15 0x0000000000000000 in ?? ()
> {noformat}
> It turns out {{ast_str_encode_mime(struct ast_str **end, ...)}} has the following line towards the start:
> {{*end = '\0';}}
> This has the effect of setting the ast_str * pointed to by 'end' to NULL - the next line:
> {{ast_str_reset(*end);}}
> Is then a NULL pointer dereference. For some reason that didn't cause a crash for me straight away, but gdb showed very quickly what was the culprit. The following patch fixes the crash for me, with no visible side-effects.
> {noformat}
> Index: apps/app_minivm.c
> ===================================================================
> --- apps/app_minivm.c   (revision 338374)
> +++ apps/app_minivm.c   (working copy)
> @@ -1159,7 +1159,6 @@
>  {
>         struct ast_str *tmp = ast_str_alloca(80);
>         int first_section = 1;
> -       *end = '\0';
>         ast_str_reset(*end);
>         ast_str_set(&tmp, -1, "=?%s?Q?", charset);
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list