Remotely triggerable crash in libpurple

Mark Doliner mark at
Mon Oct 12 04:09:25 EDT 2009

A ticket was filed yesterday where a 3rd party IM (SIM) client can
cause a crash in Pidgin when a SIM ICQ user attempts to send a list of
contacts to a Pidgin user.

I've verified this and reproduced it.  Here's a backtrace, for the curious:
(gdb) bt
#0  0x00007f99cf85cfb5 in raise () from /lib/
#1  0x00007f99cf85ebc3 in abort () from /lib/
#2  0x00000000004927cf in sighandler (sig=11) at gtkmain.c:194
#3  <signal handler called>
#4  0x00007f99cf8aac60 in strlen () from /lib/
#5  0x00007f99cf87375e in vfprintf () from /lib/
#6  0x00007f99cf928d80 in __vasprintf_chk () from /lib/
#7  0x00007f99d07114cb in g_vasprintf () from /usr/lib/
#8  0x00007f99d06fde41 in g_strdup_printf () from /usr/lib/
#9  0x00007f99c8ab89d5 in incomingim_chan4 (od=0x2392010,
conn=0x25c9790, userinfo=0x7fffdd211060, args=0x7fffdd210f90, t=0) at
#10 0x00007f99c8ab9143 in purple_parse_incoming_im (od=0x2392010,
conn=0x25c9790, fr=0x25c9800) at oscar.c:3000
#11 0x00007f99c8aa1bba in incomingim_ch4 (od=0x2392010,
conn=0x25c9790, mod=0x21af8f0, frame=0x25c9800, snac=0x7fffdd2111c0,
    userinfo=0x7fffdd211060, tlvlist=0x238de70, cookie=0x235a270
"^�\222\177 at e>\226�roup") at family_icbm.c:2181
#12 0x00007f99c8aa1e14 in incomingim (od=0x2392010, conn=0x25c9790,
mod=0x21af8f0, frame=0x25c9800, snac=0x7fffdd2111c0, bs=0x25c9808)
    at family_icbm.c:2281
#13 0x00007f99c8aa2ee2 in snachandler (od=0x2392010, conn=0x25c9790,
mod=0x21af8f0, frame=0x25c9800, snac=0x7fffdd2111c0, bs=0x25c9808)
    at family_icbm.c:2795
#14 0x00007f99c8aad7cd in parse_snac (od=0x2392010, conn=0x25c9790,
frame=0x25c9800) at flap_connection.c:779
#15 0x00007f99c8aada30 in parse_flap (od=0x2392010, conn=0x25c9790,
frame=0x25c9800) at flap_connection.c:859
#16 0x00007f99c8aadd93 in flap_connection_recv (conn=0x25c9790) at
#17 0x00007f99c8aaddfc in flap_connection_recv (conn=0x7fffdd211290)
at flap_connection.c:1007
#18 0x0000000000475541 in pidgin_io_invoke (source=0x2373120,
condition=G_IO_IN, data=0xeea9c0) at gtkeventloop.c:78
#19 0x00007f99d06dc20a in g_main_context_dispatch () from
#20 0x00007f99d06df8e0 in ?? () from /usr/lib/
#21 0x00007f99d06dfdad in g_main_loop_run () from /usr/lib/
#22 0x00007f99d3bddbc7 in gtk_main () from /usr/lib/
#23 0x0000000000493a83 in main (argc=1, argv=0x7fffdd2138b8) at gtkmain.c:916

The format of the ICBM sent to us by SIM is pretty different from what
we're expecting, and I'm not quite sure why yet.  But it's pretty easy
to fix the erroneous assumptions in our code.  Can one or two people
look at the attached patch and also maybe the little bit of the
affected function and make sure I'm not missing anything?

If all looks well with the patch then I propose throwing together a
lightweight 2.6.3, which is 2.6.2+this fix+any other small and
important bug fixes, with a minimum of string changes.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_for_10481.diff
Type: text/x-patch
Size: 2454 bytes
Desc: not available
URL: <>

More information about the security mailing list