From owner-freebsd-bugs@FreeBSD.ORG Fri Nov 8 17:20:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.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 ESMTP id 62509664 for ; Fri, 8 Nov 2013 17:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 408172635 for ; Fri, 8 Nov 2013 17:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA8HK2xp019763 for ; Fri, 8 Nov 2013 17:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA8HK2Wn019762; Fri, 8 Nov 2013 17:20:02 GMT (envelope-from gnats) Resent-Date: Fri, 8 Nov 2013 17:20:02 GMT Resent-Message-Id: <201311081720.rA8HK2Wn019762@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Valery Ushakov Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F17D85EA for ; Fri, 8 Nov 2013 17:13:28 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DDDFF25FC for ; Fri, 8 Nov 2013 17:13:28 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id rA8HDSkw055525 for ; Fri, 8 Nov 2013 17:13:28 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id rA8HDSuO055522; Fri, 8 Nov 2013 17:13:28 GMT (envelope-from nobody) Message-Id: <201311081713.rA8HDSuO055522@oldred.freebsd.org> Date: Fri, 8 Nov 2013 17:13:28 GMT From: Valery Ushakov To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/183792: Infinite loop in libalias X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:20:02 -0000 >Number: 183792 >Category: kern >Synopsis: Infinite loop in libalias >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Nov 08 17:20:01 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Valery Ushakov >Release: N/A >Organization: >Environment: >Description: _attach_handler() in libalias/alias_mod.c looks like it was originally written with hand-rolled list code and later converted to BSD macros incorrectly. Wrong comment after LIST_FOREACH loop is a strong hint. The fact that _detach_handler() uses a loop is another indication: LISTs are double-linked, so LIST_REMOVE can be done directly. What was intended there in _attach_handler() is to append to the list, but b != NULL is unreachable since b is always NULL after the loop. So the new element that should have been appended is prepended instead, breaking the ordering of handler_chain that the loop assumes. Under certain order of calls this may lead to creating of infinite loop in the handler_chain. Consider adding a handler with priority 1, then another one with priority 2, than the first handler again. The list will be: { 1 } { 2, 1 } -- BUG: 2 is prepended instead of appended { 1, 2, 1, ... } - 1 is inserted before 2, creating infinite loop The problem was originally reported by Yohanes Nugroho on vbox-dev mailing list: https://www.virtualbox.org/pipermail/vbox-dev/2013-November/011936.html though the suggested fix provided there is incorrect - it just hides the bug for the particular ordering of the calls involved in that scenario. The proper fix is to change handler_chain to a queue so that appending to it is possible. While there, _detach_handler() should drop the loop and just use remove operation directly since double-linked lists/queues support that. >How-To-Repeat: >Fix: Change handler_chain to a queue. >Release-Note: >Audit-Trail: >Unformatted: