From patchwork Tue Feb 2 18:37:35 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Manuel Bouyer X-Patchwork-Id: 12062607 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1018CC433E0 for ; Tue, 2 Feb 2021 18:37:55 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5963564F92 for ; Tue, 2 Feb 2021 18:37:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5963564F92 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=antioche.eu.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.80692.147781 (Exim 4.92) (envelope-from ) id 1l70YY-0006JU-7I; Tue, 02 Feb 2021 18:37:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 80692.147781; Tue, 02 Feb 2021 18:37:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l70YY-0006JN-4Q; Tue, 02 Feb 2021 18:37:42 +0000 Received: by outflank-mailman (input) for mailman id 80692; Tue, 02 Feb 2021 18:37:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l70YW-0006JI-At for xen-devel@lists.xen.org; Tue, 02 Feb 2021 18:37:40 +0000 Received: from isis.lip6.fr (unknown [2001:660:3302:283c::2]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2c3b8160-42e0-4667-b88a-7629e24dddfd; Tue, 02 Feb 2021 18:37:38 +0000 (UTC) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.15.2/8.15.2) with ESMTP id 112Ibaqt002576 for ; Tue, 2 Feb 2021 19:37:36 +0100 (CET) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.14.4) with ESMTP id 112IbaKq013885 for ; Tue, 2 Feb 2021 19:37:36 +0100 (MET) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 00A467120; Tue, 2 Feb 2021 19:37:35 +0100 (MET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2c3b8160-42e0-4667-b88a-7629e24dddfd Date: Tue, 2 Feb 2021 19:37:35 +0100 From: Manuel Bouyer To: xen-devel@lists.xen.org Subject: xenstored file descriptor leak Message-ID: <20210202183735.GA25046@mail.soc.lip6.fr> MIME-Version: 1.0 Content-Disposition: inline X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (isis.lip6.fr [132.227.60.2]); Tue, 02 Feb 2021 19:37:36 +0100 (CET) X-Scanned-By: MIMEDefang 2.78 on 132.227.60.2 Hello, on NetBSD I'm tracking down an issue where xenstored never closes its file descriptor to /var/run/xenstored/socket and instead loops at 100% CPU on these descriptors. xenstored loops because poll(2) returns a POLLIN event for these descriptors but they are marked is_ignored = true. I'm seeing this with xen 4.15, 4.13 and has also been reported with 4.11 with latest security patches. It seems to have started with patches for XSA-115 (A user reported this for 4.11) I've tracked it down to a difference in poll(2) implementation; it seems that linux will return something that is not (POLLIN|POLLOUT) when a socket if closed; while NetBSD returns POLLIN (this matches the NetBSD's man page). First I think there may be a security issue here, as, even on linux it should be possible for a client to cause a socket to go to the is_ignored state, while still sending data and cause xenstored to go to a 100% CPU loop. I think this is needed anyway: Now I wonder if, on NetBSD at last, a read error or short read shouldn't cause the socket to be closed, as with: @@ -1561,6 +1565,8 @@ bad_client: ignore_connection(conn); + /* we don't want to keep this connection alive */ + talloc_free(conn); } static void handle_output(struct connection *conn) what do you think ? Reviewed-by: Jürgen Groß --- xenstored_core.c.orig 2021-02-02 18:06:33.389316841 +0100 +++ xenstored_core.c 2021-02-02 19:27:43.761877371 +0100 @@ -397,9 +397,12 @@ !list_empty(&conn->out_list))) *ptimeout = 0; } else { - short events = POLLIN|POLLPRI; - if (!list_empty(&conn->out_list)) - events |= POLLOUT; + short events = 0; + if (!conn->is_ignored) { + events |= POLLIN|POLLPRI; + if (!list_empty(&conn->out_list)) + events |= POLLOUT; + } conn->pollfd_idx = set_fd(conn->fd, events); } }