From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSFRp-0004zk-Pe for qemu-devel@nongnu.org; Wed, 28 Jan 2009 13:47:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSFRp-0004z9-71 for qemu-devel@nongnu.org; Wed, 28 Jan 2009 13:47:37 -0500 Received: from [199.232.76.173] (port=45491 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSFRp-0004z2-1k for qemu-devel@nongnu.org; Wed, 28 Jan 2009 13:47:37 -0500 Received: from [84.20.150.76] (port=60979 helo=narury.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LSFRo-0005BT-GH for qemu-devel@nongnu.org; Wed, 28 Jan 2009 13:47:36 -0500 Received: from kos.to (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by narury.org (Postfix) with ESMTP id 8591B3274004 for ; Wed, 28 Jan 2009 20:47:28 +0200 (EET) Date: Wed, 28 Jan 2009 20:47:28 +0200 From: Riku Voipio Message-ID: <20090128184728.GA29590@kos.to> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] [PATCH] 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 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 --- linux-user/syscall.c | 29 +++++++++++++++++++++++++++-- 1 files changed, 27 insertions(+), 2 deletions(-) diff --git a/linux-user/syscall.c b/linux-user/syscall.c index 2903bf3..c3f5425 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include @@ -916,13 +917,37 @@ static inline abi_long target_to_host_sockaddr(struct sockaddr *addr, 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) { + 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; @@ -1376,7 +1401,7 @@ static abi_long do_bind(int sockfd, abi_ulong target_addr, 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)); -- 1.5.6.5 -- "rm -rf" only sounds scary if you don't have backups