Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
tags 631729 + patch
thanks
Hi,
I used “nc -4 -l -p 5222” to simulate a local jabber server, then
started irssi, used /load xmpp and /xmppconnect -h localhost f@b to
trigger the issue.
Attached you can find the patch with which I have come up. Here is the
description:
Previously, loudmouth would set socket-watch_connect to NULL when
encountering an error. When the connection attempt (to a different
IPv6) succeeded later on, _lm_socket_succeeded would therefore not
remove the socket_connect_cb watcher, leading to socket_connect_cb
being called upon socket activity and segfaulting the program.
This patch fixes the issue for me, but I don’t use irssi-plugin-xmpp
normally, so testing/review is welcome.
--
Best regards,
Michael
Description: fix crash when falling back from IPv6 to IPv4
Previously, loudmouth would set socket-watch_connect to NULL when
encountering an error. When the connection attempt (to a different IPv6)
succeeded later on, _lm_socket_succeeded would therefore not remove the
socket_connect_cb watcher, leading to socket_connect_cb being called upon
socket activity and segfaulting the program.
Author: Michael Stapelberg stapelb...@debian.org
Bug-Debian: http://bugs.debian.org/631729
Last-Update: 2013-01-28
--- loudmouth-1.4.3.orig/loudmouth/lm-socket.c
+++ loudmouth-1.4.3/loudmouth/lm-socket.c
@@ -529,7 +529,6 @@ socket_connect_cb (GIOChannel *source,
/* error condition, but might be possible to recover
* from it (by connecting to the next host) */
if (!_lm_socket_failed_with_error (connect_data, err)) {
-socket-watch_connect = NULL;
goto out;
}
}
@@ -560,7 +559,6 @@ socket_connect_cb (GIOChannel *source,
_lm_sock_close (connect_data-fd);
_lm_socket_failed_with_error (connect_data, err);
-socket-watch_connect = NULL;
goto out;
}
}
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
Hello, Florian Schlichting fschl...@zedat.fu-berlin.de (23/01/2013): As this only happens for me when connecting to a host that resolves to both ipv4 and ipv6 (for irssi-plugin-xmpp that is: '/xmppconnect -h localhost jid', NOT '/xmppconnect -h 127.0.0.1 jid'), I suppose the GIO watch is triggered once for each protocol version. This may either be a bug in glib, or needs to be caught in libloudmouth. I now realize that things may be a bit more complicated than that, as connections to e.g. 'inva...@twattle.net' result in a faultless ipv6 connection that continues all the way through to the password prompt. Perhaps the issue is limited to cases where the name resolution happens via /etc/hosts, and returns results for both protocols? (It is *not* limited to connections to localhost, it also happens when /etc/hosts specifies both an ipv4 and an ipv6 address for a remote host.) And KiBi, is your use case covered by these considerations? thanks, that definitely helps. Trying to find where the regression came from, I couldn't find any irssi/xmpp plugin/loudmouth/libasyncns combination allowing me to get back a connection to my server; I even went back to squeeze, and nothing worked. That IPv6 lead looks promising as the bug reporting date is consistent with the IPv6 tunnel request on the server side, according to sixxs' web interface. As for /etc/hosts, I got DNS returning both IPv4 and IPv6 for “mraw.org”; forcing IPv4 only through /etc/hosts leads to a successful connection. Having both IPv4 and IPv6 in there leads to the same kind of breakages. Forcing IPv6 only through /etc/hosts leads to no failure, even if I can check good behaviour for real since ejabberd isn't IPv6 enabled by default, and I'm having troubles making it behave properly on restart (even with its original config). So yeah, double-stack (through DNS and/or /etc/hosts) seems to be the ultimate culprit here. Mraw, KiBi. signature.asc Description: Digital signature
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
Control: reassign 631729 libloudmouth1-0 Control: retitle 631729 libloudmouth1-0: segfaults when connecting to a dual-stacked host Control: tags 631729 = ipv6 I am able to reproduce this now, both on i386 and amd64. The key is to connect to a hostname that resolves to both an IPv4 and an IPv6 address (there seems to have been a time when new installs created an /etc/hosts where this was the case for 'localhost', hence the difference between local and remote connections for some users). This is valgrind's memcheck output: ==11869== Invalid read of size 4 ==11869==at 0x4F384EE: socket_connect_cb (lm-socket.c:518) ==11869==by 0x427417D: g_io_unix_dispatch (giounix.c:166) ==11869==by 0x4233D85: g_main_context_dispatch (gmain.c:2539) ==11869==by 0x4234124: g_main_context_iterate.isra.21 (gmain.c:3146) ==11869==by 0x4234200: g_main_context_iteration (gmain.c:3207) ==11869==by 0x45204D2: (below main) (libc-start.c:226) ==11869== Address 0x512e58c is 4 bytes inside a block of size 24 free'd ==11869==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==11869==by 0x4239D0A: standard_free (gmem.c:98) ==11869==by 0x4239F8F: g_free (gmem.c:252) ==11869==by 0x4F37A0D: _lm_socket_succeeded (lm-socket.c:415) ==11869==by 0x4F386E9: socket_connect_cb (lm-socket.c:552) ==11869==by 0x427417D: g_io_unix_dispatch (giounix.c:166) ==11869==by 0x4233D85: g_main_context_dispatch (gmain.c:2539) ==11869==by 0x4234124: g_main_context_iterate.isra.21 (gmain.c:3146) ==11869==by 0x4234200: g_main_context_iteration (gmain.c:3207) ==11869==by 0x45204D2: (below main) (libc-start.c:226) And the backtrace is, as above: #0 lm_socket_ref (socket=0x100010003) at lm-socket.c:1208 #1 0x7faa7563f6df in socket_connect_cb (source=0x1297750, condition=G_IO_OUT, connect_data=0x1294020) at lm-socket.c:518 #2 0x7faa77752355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7faa77752688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7faa77752744 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x0041905c in main () Looking at loudmouth's loudmouth/lm-socket.c, it seems clear to me that socket_connect_cb is called twice with condition G_IO_OUT, while expecting for this to happen no more than once, so that on the second invocation, connect_data-socket has already been freed. As this only happens for me when connecting to a host that resolves to both ipv4 and ipv6 (for irssi-plugin-xmpp that is: '/xmppconnect -h localhost jid', NOT '/xmppconnect -h 127.0.0.1 jid'), I suppose the GIO watch is triggered once for each protocol version. This may either be a bug in glib, or needs to be caught in libloudmouth. Florian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
As this only happens for me when connecting to a host that resolves to both ipv4 and ipv6 (for irssi-plugin-xmpp that is: '/xmppconnect -h localhost jid', NOT '/xmppconnect -h 127.0.0.1 jid'), I suppose the GIO watch is triggered once for each protocol version. This may either be a bug in glib, or needs to be caught in libloudmouth. I now realize that things may be a bit more complicated than that, as connections to e.g. 'inva...@twattle.net' result in a faultless ipv6 connection that continues all the way through to the password prompt. Perhaps the issue is limited to cases where the name resolution happens via /etc/hosts, and returns results for both protocols? (It is *not* limited to connections to localhost, it also happens when /etc/hosts specifies both an ipv4 and an ipv6 address for a remote host.) And KiBi, is your use case covered by these considerations? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
Control: severity 631729 serious Florian Schlichting fschl...@zedat.fu-berlin.de (11/06/2012): severity 631729 normal retitle 631729 irssi-plugin-xmpp: segfaults when connecting to local Prosody tags 631729 + unreproducible thanks So you asked two guys to see if it's reproducible, one of them says yes, and you downgrade the bug without cc'ing the other (who happened to have skipped replying since there was already a “still happening reply”)? Not happy. Still happening to me with: ii irssi 0.8.15-5 ii irssi-plugin-xmpp 0.52-1 ii irssi-scripts 20120326 starting irssi --config /dev/null and with a single /xmppconnect foo bar Resetting severity; please don't drop the submitter in further replies. Mraw, KiBi. signature.asc Description: Digital signature
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
severity 631729 normal retitle 631729 irssi-plugin-xmpp: segfaults when connecting to local Prosody tags 631729 + unreproducible thanks Hi Adrien, I'm lowering the severity of this bug, so that it no longer blocks migration of irssi-plugin-xmpp to testing, because 1) this is no longer the issue that was originally reported (memory corruption) 2) unlike the original issue, it doesn't occur under all circumstances and for all xmpp connections 3) I'm unable to reproduce the issue, neither when connecting to a local Prosody freshly installed, nor with the prosody.im server. #0 lm_socket_ref (socket=0x20676e69) at lm-socket.c:1208 #1 0xb76be231 in socket_connect_cb (source=0x81cc9e8, condition=G_IO_OUT, connect_data=0x81cc990) at lm-socket.c:518 #2 0xb7d5145e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb7d10633 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb7d109d0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb7d10ab1 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #6 0x0805c66c in main () No part of this is irssi-plugin-xmpp itself. lm-socket.c is from libloudmouth, I believe. Which versions of irssi, prosody, libloudmouth are you using? $ dpkg -l '*loudmouth*' irssi irssi-plugin-xmpp prosody ii irssi0.8.15-5terminal based IRC client ii irssi-plugin-xmpp0.52-1 XMPP plugin for irssi ii libloudmouth1-0 1.4.3-8 Lightweight C Jabber library ii prosody 0.8.2-2 Lightweight Jabber/XMPP server written in Lua And you're on i386, whereas I'm testing amd64, right? Yep, still happening??? Maybe it's linked to my own installation, but I don't know where to start from??? If I've misunderstood you and you *do* still get double free or corruption (rather than a segfault), please try running irssi under valgrind as KiBi suggested, but connecting and authenticating to my local prosody, I don't see any issues... Florian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
Le 11/06/2012 22:49, Florian Schlichting a écrit : #0 lm_socket_ref (socket=0x20676e69) at lm-socket.c:1208 #1 0xb76be231 in socket_connect_cb (source=0x81cc9e8, condition=G_IO_OUT, connect_data=0x81cc990) at lm-socket.c:518 #2 0xb7d5145e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb7d10633 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb7d109d0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb7d10ab1 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #6 0x0805c66c in main () No part of this is irssi-plugin-xmpp itself. lm-socket.c is from libloudmouth, I believe. Which versions of irssi, prosody, libloudmouth are you using? $ dpkg -l '*loudmouth*' irssi irssi-plugin-xmpp prosody ii irssi0.8.15-5terminal based IRC client ii irssi-plugin-xmpp0.52-1 XMPP plugin for irssi ii libloudmouth1-0 1.4.3-8 Lightweight C Jabber library ii prosody 0.8.2-2 Lightweight Jabber/XMPP server written in Lua ii irssi 0.8.15-5 terminal based IRC client ii irssi-plugin-xmpp 0.52-1XMPP plugin for irssi ii libloudmouth1-0 1.4.3-8 Lightweight C Jabber library ii libloudmouth1-0-dbg 1.4.3-8 Lightweight C Jabber library (debugging symbols) ii prosody 0.8.2-2 Lightweight Jabber/XMPP server written in Lua And you're on i386, whereas I'm testing amd64, right? Yes, that's right. That may be why this isn't reproducible. Yep, still happening??? Maybe it's linked to my own installation, but I don't know where to start from??? If I've misunderstood you and you *do* still get double free or corruption (rather than a segfault), please try running irssi under valgrind as KiBi suggested, but connecting and authenticating to my local prosody, I don't see any issues... Using irssi without any tool gives me the traditional Segmentation fault right after the xmppconnect command. However, I'll try valgrind later, I don't have the time now. Thanks for taking care of this case ! Adrien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
Hello Cyril and Adrien, Do you still have this problem with irssi-plugin-xmpp 0.52-1 ? Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
Le sam. 26 mai 2012 19:44:19 CEST, Bart Martens a écrit : Hello Cyril and Adrien, Do you still have this problem with irssi-plugin-xmpp 0.52-1 ? Regards, Bart Martens #0 lm_socket_ref (socket=0x20676e69) at lm-socket.c:1208 #1 0xb76be231 in socket_connect_cb (source=0x81cc9e8, condition=G_IO_OUT, connect_data=0x81cc990) at lm-socket.c:518 #2 0xb7d5145e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb7d10633 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb7d109d0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb7d10ab1 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #6 0x0805c66c in main () Yep, still happening… Maybe it's linked to my own installation, but I don't know where to start from… -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
Hi, I confirm that loading XMPP plugin works fine, but trying to connect to an xmpp server simply crash irssi. I'm available to test if needed. Adrien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect
Package: irssi-plugin-xmpp Version: 0.51+cvs20100627-1 Severity: grave Justification: renders package unusable Hi, the xmpp plugin is unfortunately unusable these days; given its version didn't change, it might be a problem with libloudmouth1-0 or libasyncns. To reproduce, with no irssi configuration: | /load xmpp | /xmppconnect u...@example.com password The results vary between: | *** glibc detected *** /usr/bin/irssi: double free or corruption (out): 0x7fffe8000a00 *** and various inconsistent backtraces pointing to various places of libloudmouth1-0 and libasyncns, with no useful information, so I'm not pasting them. Wild guess: valgrind should make it easy to track it down. I might try and downgrade various packages to see whether I can come back to a better situation. Mraw, KiBi. -- System Information: Debian Release: sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages irssi-plugin-xmpp depends on: ii irssi0.8.15-4+debug1 terminal based IRC client ii libc62.13-7 Embedded GNU C Library: Shared lib ii libglib2.0-0 2.28.6-1The GLib library of C routines ii libidn11 1.20-1 GNU Libidn library, implementation ii libloudmouth1-0 1.4.3-7 Lightweight C Jabber library irssi-plugin-xmpp recommends no packages. irssi-plugin-xmpp suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
