[sr-dev] [tracker] Task opened: Segfault parsing STUN body

[sip-router]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Francesco Castellano (fcastellano) 

Attached to Project - sip-router
Summary - Segfault parsing STUN body
Task Type - Bug Report
Category - stun
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - Linux
Severity - High
Priority - Normal
Reported Version - 3.1
Due in Version - Undecided
Due Date - Undecided
Details - After upgrading to kamailio 3.1.3, with STUN enabled, our proxy experienced random segfault to udp worker processes. Recompiling with symbols and extra_debug, and analysing the coredumps with a collegue of mine, it appeared that the problem lies somewhere in ser_stun.c (actually after our findings tunrning off stun_allow_stun, the segfaults ended).

(gdb) bt
#0  0x00007f6e54964785 in memcpy () from /lib/libc.so.6
#1  0x00000000004ced6c in stun_parse_body (req=0x7fffa26a7140, unknown=0x7fffa26a70a8, error_code=0x7fffa26a70a6) at ser_stun.c:268
#2  0x00000000004ce427 in stun_process_msg (buf=0x8dee20 "", len=36, ri=0x7fffa26a71e0) at ser_stun.c:127
#3  0x000000000051a3eb in udp_rcv_loop () at udp_server.c:526
#4  0x000000000045ecce in main_loop () at main.c:1554
#5  0x0000000000461aad in main (argc=13, argv=0x7fffa26a7508) at main.c:2398

Ah, our system is x86_64; kamailio, as apparent, was compiled by ourselves for having STUN enabled. For the version with symbols the core flags were:

version: kamailio 3.1.3 (x86_64/linux) 8b3506
flags: STATS: Off, EXTRA_DEBUG, USE_IPV6, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, USE_STUN, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 32MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 8b3506 
compiled on 03:32:10 Apr 28 2011 with gcc 4.4.5

But the segfaults were firstly noticed on a core with:

version: kamailio 3.1.3 (x86_64/linux) 8b3506
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, USE_STUN, DISABLE_NAGLE, USE_MCAST, NO_DEBUG, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 32MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 8b3506 
compiled on 03:37:09 Apr 28 2011 with gcc 4.4.5

In particular, during the while loop for processing the STUN body attributes, it seems that something wrong prevented breaking the loop. Our attention focused on an attr.type 0x8022 (in the file it matched SERVER_ATTR, and, if I understand correctly, it is the same as the SOFTWARE attribute in rfc5389). Calculating the padded_len in ser_stun.c:307 via the PADDED_TO_FOUR macro; and being in our case ntohs(attr.len) = 12; the padded_len resulted in 16 (is this correct? The PADDED_TO_FOUR name suggests that 12 *is* padded to four); so that not_parsed (it was 12, and it was declared UINT_T) bacame something odd: (UINT_T) (12 - 16).

I'm sorry having be a little detailed; but I hope this can help the developers in fixing it.

I don't attach any cores because they are quite large (2GB each); but having them, I can add informations if you please. Moreover, even if I haven't replicated it yet in a controlled manner; I don't think it is a complex task.

Best regards,
Francesco Castellano

More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=129

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.