From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lu7iT-0001G3-Vh for qemu-devel@nongnu.org; Wed, 15 Apr 2009 12:12:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lu7iT-0001FV-Bl for qemu-devel@nongnu.org; Wed, 15 Apr 2009 12:12:01 -0400 Received: from [199.232.76.173] (port=48815 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lu7iT-0001FM-3B for qemu-devel@nongnu.org; Wed, 15 Apr 2009 12:12:01 -0400 Received: from savannah.gnu.org ([199.232.41.3]:50086 helo=sv.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lu7iS-0003Or-Mr for qemu-devel@nongnu.org; Wed, 15 Apr 2009 12:12:00 -0400 Received: from cvs.savannah.gnu.org ([199.232.41.69]) by sv.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Lu7iS-0007D0-5n for qemu-devel@nongnu.org; Wed, 15 Apr 2009 16:12:00 +0000 Received: from aurel32 by cvs.savannah.gnu.org with local (Exim 4.69) (envelope-from ) id 1Lu7iR-0007Ch-Q6 for qemu-devel@nongnu.org; Wed, 15 Apr 2009 16:12:00 +0000 MIME-Version: 1.0 Errors-To: aurel32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Aurelien Jarno Message-Id: Date: Wed, 15 Apr 2009 16:11:59 +0000 Subject: [Qemu-devel] [7116] linux-user: unix sockets - fix running dbus Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Revision: 7116 http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=7116 Author: aurel32 Date: 2009-04-15 16:11:59 +0000 (Wed, 15 Apr 2009) Log Message: ----------- linux-user: unix sockets - fix running dbus dbus sends too short (according to man 7 unix) addrlen for it's unix socket. I've been told that happens with other applications as well. Linux kernel doesn't appear to mind, so I guess we whould be tolerant as well. Expand sockaddr with +1 to fit the \0 of the pathname passed. (scratchbox1 qemu had a very different workaround for the same issue). Signed-off-by: Riku Voipio Signed-off-by: Aurelien Jarno Modified Paths: -------------- trunk/linux-user/syscall.c Modified: trunk/linux-user/syscall.c =================================================================== --- trunk/linux-user/syscall.c 2009-04-15 16:11:52 UTC (rev 7115) +++ trunk/linux-user/syscall.c 2009-04-15 16:11:59 UTC (rev 7116) @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include @@ -735,13 +736,37 @@ abi_ulong target_addr, socklen_t len) { + const socklen_t unix_maxlen = sizeof (struct sockaddr_un); + sa_family_t sa_family; struct target_sockaddr *target_saddr; target_saddr = lock_user(VERIFY_READ, target_addr, len, 1); if (!target_saddr) return -TARGET_EFAULT; + + sa_family = tswap16(target_saddr->sa_family); + + /* Oops. The caller might send a incomplete sun_path; sun_path + * must be terminated by \0 (see the manual page), but + * unfortunately it is quite common to specify sockaddr_un + * length as "strlen(x->sun_path)" while it should be + * "strlen(...) + 1". We'll fix that here if needed. + * Linux kernel has a similar feature. + */ + + if (sa_family == AF_UNIX) { + if (len < unix_maxlen && len > 0) { + char *cp = (char*)target_saddr; + + if ( cp[len-1] && !cp[len] ) + len++; + } + if (len > unix_maxlen) + len = unix_maxlen; + } + memcpy(addr, target_saddr, len); - addr->sa_family = tswap16(target_saddr->sa_family); + addr->sa_family = sa_family; unlock_user(target_saddr, target_addr, 0); return 0; @@ -1195,7 +1220,7 @@ if (addrlen < 0 || addrlen > MAX_SOCK_ADDR) return -TARGET_EINVAL; - addr = alloca(addrlen); + addr = alloca(addrlen+1); target_to_host_sockaddr(addr, target_addr, addrlen); return get_errno(bind(sockfd, addr, addrlen));