[ASTERISK-181] chan_iax2: Memory corruption with video frames

← All Issues || New Issue →

Sort Normal || Priority

Details

Crash that occurred even on a system patch with this fix (and it seems like a similar type of problem to [ASTERISK-171], though not identical): https://github.com/asterisk/asterisk/pull/1708/changes

[2026-04-04 04:08:01.981]     -- Executing [s@ringback-phreaknet:1] Progress("IAX2/phreaknet-4969", "") in new stack
[2026-04-04 04:08:01.981]     -- Executing [s@ringback-phreaknet:2] PlayTones("IAX2/phreaknet-4969", "600*120") in new stack
[2026-04-04 04:08:01.982]     -- Executing [s@ringback-phreaknet:3] Wait("IAX2/phreaknet-4969", "60") in new stack
[2026-04-04 04:08:03.664] WARNING[1989160]: chan_iax2.c:10492 socket_process_helper: Packet Decrypt Failed!
[2026-04-04 04:08:04.891] ERROR[1989167]: iax2/parser.c:1213 iax_frame_wrap: Losing frame data because destination buffer size '4096' bytes not big enough for '-1' bytes in the frame
[2026-04-04 04:08:04.891] ERROR[1989167]: iax2/parser.c:1213 iax_frame_wrap: Losing frame data because destination buffer size '4096' bytes not big enough for '-1' bytes in the frame

#6  0x000055c8bd095d7e in __ast_free
    (ptr=0x7f06288f7770, file=0x7f064d67107c "iax2/parser.c", lineno=1334, func=0x7f064d671398 <__PRETTY_FUNCTION__.0> "iax_frame_free") at astmm.c:473
#7  0x00007f064d663604 in iax_frame_free (fr=0x7f06288f7770) at iax2/parser.c:1334
#8  0x00007f064d60e829 in iax2_frame_free (fr=0x7f06288f7770) at chan_iax2.c:2207
#9  0x00007f064d613b95 in __do_deliver (data=0x7f06288f7770) at chan_iax2.c:3424
#10 0x00007f064d6172cc in schedule_delivery (fr=0x7f06288f7770, updatehistory=1, fromtrunk=0, tsout=0x7f06094c5e98) at chan_iax2.c:4358
#11 0x00007f064d6471b2 in socket_process_helper (thread=0x55c8c764b550) at chan_iax2.c:12170
#12 0x00007f064d647393 in socket_process (thread=0x55c8c764b550) at chan_iax2.c:12189
#13 0x00007f064d647ac6 in iax2_process_thread (data=0x55c8c764b550) at chan_iax2.c:12299
#14 0x000055c8bd262e34 in dummy_start (data=0x55c8c4c582a0) at utils.c:1641
#15 0x00007f064f9aeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#16 0x00007f064fa2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6

#11 0x00007f064d6471b2 in socket_process_helper (thread=0x55c8c764b550) at chan_iax2.c:12170
12170                           schedule_delivery(duped_fr, updatehistory, 0, &fr->ts);
(gdb) print *duped_fr
$4 = {sockfd = 0, callno = 4969, dcallno = 0, data = 0x0, datalen = 0, retries = 0, ts = 4294962794, retrytime = 0, outoforder = 1, sentyet = 0,
  transfer = 0, final = 0, direction = 1, cacheable = 1, oseqno = 0, iseqno = 0, retrans = -1, encmethods = 0, ecx = {raw = '\000' <repeats 15 times>},
  mydcx = {raw = '\000' <repeats 15 times>}, semirand = '\000' <repeats 31 times>, list = {next = 0x0}, af = {frametype = AST_FRAME_VIDEO, subclass = {
      integer = 0, {format = 0x55c8c4574c98, topology = 0x55c8c4574c98}, frame_ending = 0}, datalen = -1, samples = 0, mallocd = 0, mallocd_hdr_len = 0,
    offset = 64, src = 0x7f064d66624c "IAX2", data = {ptr = 0x7f06288f78c0, uint32 = 680491200, pad = "\300x\217(\006\177\000"}, delivery = {tv_sec = 0,
      tv_usec = 0}, frame_list = {next = 0x0}, flags = 0, ts = 0, len = 0, seqno = 0, stream_num = 0}, afdatalen = 18446744073709551615,
  unused = '\000' <repeats 63 times>, afdata = 0x7f06288f78c0 "A"}
(gdb)

The affected system didn't have the assertion on line 1213 of parser.c, which would have triggered an immediate core dump at that point. Nonetheless, the fact that it got there means there is still some call path capable of causing issues (which isn't reflected in the backtrace, since we would have needed to crash immediately to see that). I've added the assertion on the affected system so if this happens again, we should have more context.

Comments

You must be logged in to leave a comment.