[asterisk-bugs] [JIRA] (ASTERISK-28294) Segmentation Fault on strchr

[Salah Ahmed (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246257#comment-246257 ] 

Salah Ahmed edited comment on ASTERISK-28294 at 2/19/19 10:17 AM:
------------------------------------------------------------------

Hello George,

Actually I didn't reproduce this in my environment. This logic is seems suspicious to me after some gdb analysis. If there have no possibility of 0 magic value then, somehow this value set to 0 in my environment and that causes the crash.

Just to share, In Frame-2 logmsg has following data,

{code}
(gdb) p *logmsg
$2 = {type = LOGMSG_VERBOSE, level = 5, line = 4350, lwp = 18847, callid = 0x7feda0001298, __field_mgr_pool = 0x7feda00042e0, date = 0x7feda0004368 "Feb 14 20:04:36", 
  file = 0x7feda0004384 "pbx.c", function = 0x7feda000438c "__ast_pbx_run", message = 0x7feda0004302 "", level_name = 0x7feda000437a "VERBOSE", __field_mgr = {
    last_alloc = 0x7feda000438c "__ast_pbx_run", header = 0x7feda0005010}, list = {next = 0x0}}
{code}

This message = "" create level = -1 and eventually it set 0 to magic value. 

Thank You,  


was (Author: rubel):
Hello George,

Actually I didn't reproduce this in my environment. This logic is seems suspicious to me after some gdb analysis. If there have no possibility of 0 magic value then, somehow this value set to 0 in my environment and that causes the crash.

Thank You,  

> Segmentation Fault on strchr 
> -----------------------------
>
>                 Key: ASTERISK-28294
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28294
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Logging
>    Affects Versions: 13.24.1
>            Reporter: Salah Ahmed
>            Assignee: Unassigned
>            Severity: Minor
>              Labels: fax
>
> Hi,
> Recently we have experiencing a crash on our system. gdb core dump report following,
> {code}
> #1  0x000000000053a47f in logger_strip_verbose_magic (message=0x7feda0004302 "", level=-1) at logger.c:1366
>         begin = 0x7feda0032000 <error: Cannot access memory at address 0x7feda0032000>
>         end = 0x7feda0031fff ""
>         stripped_message = 0x7fee18000a80 " (keepalive-fax, keepalive-fax, 7) exited non-zero on 'PJSIP/ser02-000001b1'\n\020Feb 14 20:04:36\bVERBOSE\006pbx.c\016__ast_pbx_run5\340N\240\355\177\027\027\065\320O\240\355\177\200I\240\355\177Q\001x\240\355\177\240\025\240\355\177\350G\240\355\177&l\376zpd\300@\240\355\177\377\377\377\377\300\004\064SUCCESS@(\240\355\177\261\240\t\240\355\177\340I\240"...
>         dst = 0x7fee1800480b ""
>         magic = 0 '\000'
>         __PRETTY_FUNCTION__ = "logger_strip_verbose_magic"
> #2  0x000000000053a5d2 in logger_print_normal (logmsg=0x7feda0004280) at logger.c:1400
>         chan = 0x0
>         buf = "Executing [keepalive-fax at keepalive-fax:7] ExecIf(\"PJSIP/cnhk1ser02-000001b1\", \"1?Busy()\") in new stack\n\000ive_handler\") in new stack\n\000RE ms.hostname LIKE ?    AND ms.service = vcc    AND IFNULL(ms.force"...
>         v = 0x0
>         tmpmsg = 0x7feda0004298 "\340B"
>         level = -1
>         __PRETTY_FUNCTION__ = "logger_print_normal"
> #3  0x000000000053b9e4 in logger_thread (data=0x0) at logger.c:1617
>         next = 0x0
>         msg = 0x7feda0004280
>         __PRETTY_FUNCTION__ = "logger_thread"
> #4  0x00000000005f6640 in dummy_start (data=0x2d76570) at utils.c:1238
>         __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 5944777430901416190, 0, 140660921573472, 0, 140660859598592, 5944777430876250366, -5954807578999037698}, 
>               __mask_was_saved = 0}}, __pad = {0x7fee2891eef0, 0x0, 0x0, 0x0}}
>         __cancel_routine = 0x450f0b <ast_unregister_thread>
>         __cancel_arg = 0x7fee2891f700
>         __not_first_call = 0
>         ret = 0x0
>         a = {start_routine = 0x53b821 <logger_thread>, data = 0x0, name = 0x2d766d0 "logger_thread        started at [ 1705] logger.c init_logger()"}
> #5  0x00007fee2a71f064 in start_thread (arg=0x7fee2891f700) at pthread_create.c:309
>         __res = <optimized out>
>         pd = 0x7fee2891f700
>         now = <optimized out>
>         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140660859598592, -5954806884488486658, 0, 140660921573472, 0, 140660859598592, 5944777430903513342, 5944771658510852350}, 
>               mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
>         not_first_call = <optimized out>
>         pagesize_m1 = <optimized out>
>         sp = <optimized out>
>         freesize = <optimized out>
>         __PRETTY_FUNCTION__ = "start_thread"
> #6  0x00007fee29a0762d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> {code}
> From logger.c file,
> {code}
>         do {
>                 end = strchr(begin, magic);
> 		if (end) {
>                         size_t len = end - begin;
>                         memcpy(dst, begin, len);
>                         begin = end + 1;
> 			dst += len;
>                 } else {
>                         strcpy(dst, begin); /* safe */
>                         break;
>                 }
> 	} while (1);
> {code}
> It seems, If magic is 0 then there have possibility for this crash.
> Thank You,



--
This message was sent by Atlassian JIRA
(v6.2#6252)