[asterisk-bugs] [JIRA] (ASTERISK-27170) pjproject: Unsafe usage of gethostbyname causing memory corruption

Kevin Harwell (JIRA) noreply at issues.asterisk.org
Tue Oct 24 09:33:21 CDT 2017


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

Kevin Harwell commented on ASTERISK-27170:
------------------------------------------

{quote}
You must have looked into pjproject and musl wrongly, as it is quite obvious that in the described case pj_gethostbyname is used
{quote}
Ah yes you are correct. I did miss the call from sock_common.c. I was describing what happens when a call is made to the pj_getaddrinfo method, which you were not using.
{quote}
It took some minutes to fix it after I've discovered the reasons for the memory corruptions, so I don't understand why the asterisk devs didn't integrate a fix before the pjsip team fixed it
{quote}
We have many issue to work on and we get to issues when we can. Your fix, while sufficient for your needs, was not an acceptable fix for everyone. But it appears the pjproject team cleaned it up and fixed the issue, which we're glad to hear. Thanks for letting us know!

> pjproject: Unsafe usage of gethostbyname causing memory corruption
> ------------------------------------------------------------------
>
>                 Key: ASTERISK-27170
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27170
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: PBX/General
>    Affects Versions: 13.16.0, 13.17.0
>         Environment: 64bit linux musl 1.1.16-git
>            Reporter: nappsoft
>            Assignee: Unassigned
>         Attachments: backtrace4.txt, crashlog.txt, gethostbyname_r.diff, trace_cel_crash.txt, trace.txt, valgrind2.txt, valgrind4.txt, vgcore.24994-brief.txt, vgcore.24994-full.txt, vgcore.24994-locks.txt, vgcore.24994-thread1.txt
>
>
> From time to time asterisk crashes when a component is trying to allocate memory. According to the sip traces this seem to happen mainly soon (sometimes some milliseconds, sometimes a few seconds) after a call in which a PickupChan operation was involved has been finished.



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



More information about the asterisk-bugs mailing list