From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 14:57:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB0866C4; Fri, 11 Apr 2014 14:57:02 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 72AED1457; Fri, 11 Apr 2014 14:57:02 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3BEv0w8039924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2014 15:57:01 +0100 (BST) Date: Fri, 11 Apr 2014 15:57:00 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> In-Reply-To: <20140411141526.GT21331@kib.kiev.ua> References: <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:57:03 -0000 --On 11 April 2014 17:15 +0300 Konstantin Belousov wrote: > So my suspicious idea seems to be true. From the ldd output, libc > appears before libthr in the global order, so libc sigaction() symbol > is resolved before libthr interposer. The result is that libthr wrapper > thr_sighandler() for the signal handlers is not installed as the > recepient of the kernel signal, which prevents libthr locks for rtld > from working properly. Ok, I can just about follow that ;) > To confirm or deny my theory, please apply the patch below, in addition to > the previous patch, and rebuild sshd only, ># cd src/secure/usr.sbin/sshd && make clean all install > The patch tilts the order of initialization, for my build I got > sandy% ldd /usr/sbin/sshd > ... > libz.so.6 => /lib/libz.so.6 (0x802f0d000) > libthr.so.3 => /lib/libthr.so.3 (0x803123000) > libc.so.7 => /lib/libc.so.7 (0x803348000) > libldns.so.5 => /usr/lib/private/libldns.so.5 (0x8036d1000) > libmd.so.6 => /lib/libmd.so.6 (0x803926000) > which could be enough to prevent the bug. > > Please retest and report. Ok, patched the makefile - rebuilt / installed sshd restarted (which has the same initialisation order as yours above), it and ran the security scan against it. *This does indeed seem to fix the problem* The scan completes, and there are no stuck 'urdlck' sshd's - and no socket sitting around in CLOSE_WAIT or CLOSED - thanks! :) I re-ran the scan a couple of times more to be sure, with the same result - no zombies or anything. Is this situation likely to be repeated anywhere else on the system? Or is it likely just to be specific to sshd? Many thanks again, -Karl