Package: jabberd2 Version: 2.2.17-1 Severity: normal Hi,
I'm getting frequent segfaults from jabberd2-router with the faulting address lying a good deal beyond the end of heap. Backtrace (strings redacted): ============================================================ #0 0x00007f8818a4a107 in message_log (nad=nad@entry=0x7f88197cc7f0, r=0x7f88197a4010, msg_from=0x7f88197c4c50 "...", msg_to=msg_to@entry=0x7f88197c4e30 "...") at router.c:1156 #1 0x00007f8818a4bb7a in _router_process_route (nad=0x7f88197cc7f0, comp=0x7f88197af9e0) at router.c:587 #2 _router_sx_callback (s=<optimized out>, e=<optimized out>, data=0x7f88197cc7f0, arg=0x7f88197af9e0) at router.c:948 #3 0x00007f8818a4f22a in __sx_event (file=file@entry=0x7f8818a5dae6 "io.c", line=line@entry=156, s=s@entry=0x7f88197afaa0, e=e@entry=event_PACKET, data=data@entry=0x7f88197cc7f0) at sx.c:345 #4 0x00007f8818a4d687 in _sx_process_read (s=s@entry=0x7f88197afaa0, buf=buf@entry=0x7f88197c4c80) at io.c:156 #5 0x00007f8818a4da9a in sx_can_read (s=0x7f88197afaa0) at io.c:243 #6 0x00007f8818a49ced in router_mio_callback (m=<optimized out>, a=<optimized out>, fd=0x7f88197af9b0, data=<optimized out>, arg=0x7f88197af9e0) at router.c:1047 #7 0x00007f8818a5343d in _mio_run (m=0x7f88197af7e0, timeout=<optimized out>) at mio_impl.h:268 #8 0x00007f8818a488c8 in main (argc=<optimized out>, argv=<optimized out>) at main.c:446 ============================================================ Turns out the problematic code block is this: ============================================================ 1155 // Find the message body 1156 for (i = 0; NAD_ENAME_L(nad, i) > 0; i++) 1157 { 1158 if((NAD_ENAME_L(nad, i) == 4) && (strncmp("body", NAD_ENAME(nad, i), 4) == 0)) 1159 { 1160 nad_body_len = NAD_CDATA_L(nad, i); 1161 if (nad_body_len > 0) { 1162 nad_body = NAD_CDATA(nad, i); 1163 } else { 1164 log_write(r->log, LOG_NOTICE, "message_log received a message with empty body"); 1165 return 0; 1166 } 1167 break; 1168 } 1169 } ============================================================ As long as every message has a body, this works like a charm. However, the message I received contains only {"route", "message", "event", "items", "item", "activities", "delay"}, so we loop on... However, nad->elems[] looks like this: ============================================================ (gdb) set $i=0 (gdb) p nad->elems[$i++] $38 = {parent = -1, iname = 48, lname = 5, icdata = 0, lcdata = 0, itail = 0, ltail = 0, attr = 1, ns = 0, my_ns = 0, depth = 0} (gdb) $39 = {parent = 0, iname = 89, lname = 7, icdata = 0, lcdata = 0, itail = 0, ltail = 0, attr = 3, ns = 1, my_ns = 1, depth = 1} (gdb) $40 = {parent = 1, iname = 192, lname = 5, icdata = 0, lcdata = 0, itail = 0, ltail = 0, attr = -1, ns = 2, my_ns = 2, depth = 2} (gdb) $41 = {parent = 2, iname = 197, lname = 5, icdata = 0, lcdata = 0, itail = 0, ltail = 0, attr = 4, ns = -1, my_ns = 2, depth = 3} (gdb) $42 = {parent = 3, iname = 248, lname = 4, icdata = 0, lcdata = 0, itail = 0, ltail = 0, attr = 5, ns = -1, my_ns = 2, depth = 4} (gdb) $43 = {parent = 4, iname = 309, lname = 10, icdata = 0, lcdata = 0, itail = 0, ltail = 0, attr = -1, ns = 3, my_ns = 3, depth = 5} (gdb) $44 = {parent = 1, iname = 333, lname = 5, icdata = 0, lcdata = 0, itail = 0, ltail = 0, attr = 7, ns = 4, my_ns = 4, depth = 2} (gdb) $45 = {parent = 779248994, iname = 778265443, lname = 1042769252, icdata = 1702257980, lcdata = 2015392878, itail = 1936616557, ltail = 1952982845, attr = 792359028, ns = 1650551343, my_ns = 779248994, depth = 795308655} ============================================================ I.e. the loop looks for a terminating element with zero ->lname which doesn't exist. The last is obviously already bogus, as nad->ecur proves: ============================================================ (gdb) p *nad $46 = {elems = 0x7f88197ce3e0, attrs = 0x7f88197cdbc0, nss = 0x7f88197c4e60, cdata = 0x7f88197cbab0 "..."..., depths = 0x7f88197c48f0, elen = 384, alen = 256, nlen = 128, clen = 512, dlen = 128, ecur = 7, acur = 8, ncur = 5, ccur = 400, scope = -1, next = 0x0} ============================================================ Suggested fix: loop until nad->ecur is reached instead. Jan PS: This loop is still present even in upstream 2.3.2. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org