[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openser-devel
Subject:    [sr-dev] [tracker] Task opened: Segfault parsing STUN body
From:       sip-router <admin () sip-router ! org>
Date:       2011-04-29 10:17:54
Message-ID: 20110429101754.23986.1229486519.swift () sip-router ! org
[Download RAW message or body]

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.

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


[prev in list] [next in list] [prev in thread] [next in thread]