Skip to content

Crash on free address on nua_client_request_destroy #306

@bundasmanu

Description

@bundasmanu

A strange scenario appear and can't emulate it internally.

But, looking into the backtrace, something goes wrong when c internal tries to unlink.

#1  0x00007f6e879c8122 in nua_client_request_destroy (cr=0x7f6da4131d50) at nua_client.c:385
        nh = 0x7f6db8007460
#2  nua_client_request_unref (cr=cr@entry=0x7f6da4131d50) at nua_client.c:260
No locals.
#3  0x00007f6e879c87bd in nua_client_init_request (cr=0x7f6da4131d50) at nua_client.c:445
No locals.
#4  0x00007f6e879c8ee6 in nua_client_create (nh=nh@entry=0x7f6db8007460, event=event@entry=31, methods=methods@entry=0x7f6e87c8b0c0 <nua_invite_client_methods>,
    tags=tags@entry=0x7f6db8007f00) at nua_client.c:201
        home = 0x7f6db8007460
        cr = <optimized out>
        method = <optimized out>
        name = <optimized out>
#5  0x00007f6e879df6b1 in nua_stack_invite (nua=nua@entry=0x7f6db0001180, nh=nh@entry=0x7f6db8007460, e=e@entry=nua_r_invite, tags=tags@entry=0x7f6db8007f00) at nua_session.c:709
No locals.
#6  0x00007f6e879c5973 in nua_stack_signal (nua=0x7f6db0001180, msg=<optimized out>, ee=0x7f6db8007ed8) at nua_stack.c:629
        e = 0x7f6db8007ee0
        nh = 0x7f6db8007460
        tags = 0x7f6db8007f00
        event = nua_r_invite
        error = 0
        __func__ = "nua_stack_signal"
#7  0x00007f6e87a17532 in su_base_port_execute_msgs (queue=0x0) at su_base_port.c:280
        root = <optimized out>
        f = <optimized out>
        msg = 0x0
        n = 0
#8  0x00007f6e87a17abd in su_base_port_run (self=0x7f6da40008c0) at su_base_port.c:335
        tout = 15000
        tout2 = 0
        __PRETTY_FUNCTION__ = "su_base_port_run"
#9  0x00007f6e87a181d0 in su_pthread_port_clone_main (varg=0x7f6e2a7fb960) at su_pthread_port.c:343
        arg = 0x0
        task = {{sut_port = 0x7f6da40008c0, sut_root = 0x7f6da4001130}}
        zap = 1
#10 0x00007f6e86eb2ea5 in start_thread (arg=0x7f6e29ffb700) at pthread_create.c:307
---Type <return> to continue, or q <return> to quit---
        __res = <optimized out>
        pd = 0x7f6e29ffb700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140111127754496, 8330995999063573119, 0, 8392704, 0, 140111127754496, -8268055552699760001, -8268422622153768321},
              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>
#11 0x00007f6e86506b0d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

Full backtrace:

backtrace.log

sofia-sip version: 1.13.17-8116788228.50a509b72c
freeswitch: 1.10.9
Distro: CentOS 7.9
libc: 2.17.326

memset:

(gdb) print cr
$9 = (nua_client_request_t *) 0x7f6da4131d50
(gdb) print cr->cr_sip
$10 = (sip_t *) 0xaaaaaaaaaaaaaaaa
(gdb) print cr->cr_seq
$11 = 2863311530
(gdb)
$12 = 2863311530
(gdb) print cr->cr_msg
$13 = (msg_t *) 0xaaaaaaaaaaaaaaaa
(gdb)
print cr->cr_usage
$1 = (nua_dialog_usage_t *) 0xaaaaaaaaaaaaaaaa

Any hint?
Declaring data=NULL inside su_free only masks the problem, so seems to not be plausible.
So, part of the content of cr is partially marked as free in the past (i think).

Looking at malloc logic, seems to be memory corruption...

Why, in the code we are not pointing cr_method_name and cr_phrase to NULL, like we do with other parts?

(gdb) print cr->cr_refs
$4 = 2863311530
(gdb) print cr->cr_method_name
$5 = 0xaaaaaaaaaaaaaaaa <Address 0xaaaaaaaaaaaaaaaa out of bounds>
(gdb) print cr->cr_phrase
$6 = 0xaaaaaaaaaaaaaaaa <Address 0xaaaaaaaaaaaaaaaa out of bounds>

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions