From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0173941B81; Mon, 30 Jan 2023 15:26:14 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 719CD40DFB; Mon, 30 Jan 2023 15:26:14 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id C05E540C35 for ; Mon, 30 Jan 2023 15:26:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675088771; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hP6h/ykztQAoyfTPkLSdQv05IRl6j8JfqyEjuPr3v6Y=; b=Zw1mO40wBlS05mgj+ul0OJJ81JyDPrCUWSvm/xhLPdsX6zMD3OJeDSZWgVddqQsb/o9yPt 7LAhcMDqwwEYvORJkZjXLWN7qSg7RUhg4dDUsFiEM3gC2ys1jEfTwUvX9XhzsBcNlKlzD7 vCR1qnJ2d8Awr1tb4IwZMxVIshSr4Mk= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-341-LExjAiuLNcKkHRVsthsePA-1; Mon, 30 Jan 2023 09:26:10 -0500 X-MC-Unique: LExjAiuLNcKkHRVsthsePA-1 Received: by mail-pl1-f199.google.com with SMTP id y8-20020a170902b48800b00192a600df83so6712734plr.15 for ; Mon, 30 Jan 2023 06:26:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hP6h/ykztQAoyfTPkLSdQv05IRl6j8JfqyEjuPr3v6Y=; b=IqXYtE17ptxPR4gstp/K0A8XBKjY1TQ4GfPs2VdgiO0SzS4+yDpD9+039LjAAKjJyG qkaLM7aHKZ475GdBH6GjW3ml/myRWNoFRdLSFWEWou/MNu8TNNXF1Pbq18XoUFseAfR0 2ZimqIrsE3eQOrdyZjykX0JjOayow/lpdXB/c/8Q2cyDbQIg+eBMSGN1fnafjQy7A+Su wG71sklkt8fhzDCmWWkvSZr3cjd0bZPFMk+5kvJCjnrdDTl1ZEAcqJ+hhcwi2spt4EsZ axxT3Wa129DTZa3IfUq1PL5NBHp5TVHNnMZcO4L6ffgxAwRY4nF4Vrfv9cpHE+d55Ess JFow== X-Gm-Message-State: AFqh2kpe6uHHb0NxY0gtHefD6IyobOPVmCh9f2bzAiF2J0Ncb21OCchk e8BE/QwsLQwnxCIqlkwdaWgCOeibtgL+xu+DtARKxHImjI4ctpXnS4gHp1UtKiZRcp16yN+p8He +cF0EYlLMCxiT8rnL0DU= X-Received: by 2002:a63:c052:0:b0:477:27f7:794a with SMTP id z18-20020a63c052000000b0047727f7794amr5218068pgi.58.1675088769281; Mon, 30 Jan 2023 06:26:09 -0800 (PST) X-Google-Smtp-Source: AMrXdXs/TdCBRHVfPOAf6RLieNGUufFvSHcjpOOeSVRJ9I2HZSiNmEviN7ymFwSSKP4RJU3kTQBg8d1MV6De7ZEY8vw= X-Received: by 2002:a63:c052:0:b0:477:27f7:794a with SMTP id z18-20020a63c052000000b0047727f7794amr5218058pgi.58.1675088769013; Mon, 30 Jan 2023 06:26:09 -0800 (PST) MIME-Version: 1.0 References: <20230127165540.37863-1-maxime.coquelin@redhat.com> <20230127165540.37863-2-maxime.coquelin@redhat.com> In-Reply-To: From: David Marchand Date: Mon, 30 Jan 2023 15:25:57 +0100 Message-ID: Subject: Re: [PATCH v2 1/2] vhost: fix possible FDs leak To: Maxime Coquelin Cc: dev@dpdk.org, chenbo.xia@intel.com, stable@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Jan 30, 2023 at 10:46 AM Maxime Coquelin wrote: > > > > On 1/29/23 10:25, David Marchand wrote: > > On Fri, Jan 27, 2023 at 5:55 PM Maxime Coquelin > > wrote: > >> > >> On failure, read_vhost_message() only closed the message > >> FDs if the header size was unexpected, but there are other > >> cases where it is required. For exemple in the case the > >> payload size read from the header is greater than the > >> expected maximum payload size. > >> > >> This patch fixes this by closing all messages FDs in all > >> error cases. > >> > >> Fixes: bf472259dde6 ("vhost: fix possible denial of service by leaking FDs") > >> Cc: stable@dpdk.org > >> > >> Signed-off-by: Maxime Coquelin > > > > Reviewed-by: David Marchand > > > > We mentionned offlist that the request type can be logged to help with debug. > > Do you intend to add this as a follow up patch? > > > > > > Thinking about it, that's not that trivial because read_vhost_message() > is called for both master and slave channels, so we would need to > differentiate between both to print proper request name. > > It is doable by comparing the file descriptor passed as parameter with > the slave one stored in struct virtio_net, but that's not super clean. >From the 3 different callers of read_vhost_message, I think the only one that could gain from this debug is vhost_user_msg_handler(). And here, we could look at the message content on read_vhost_message return. Like this untested and ugly snippet: diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c index 943058725e..1556f21a58 100644 --- a/lib/vhost/vhost_user.c +++ b/lib/vhost/vhost_user.c @@ -2994,13 +2994,10 @@ vhost_user_msg_handler(int vid, int fd) } } + ctx.msg.request.master = VHOST_USER_NONE; ret = read_vhost_message(dev, fd, &ctx); - if (ret <= 0) { - if (ret < 0) - VHOST_LOG_CONFIG(dev->ifname, ERR, "vhost read message failed\n"); - else - VHOST_LOG_CONFIG(dev->ifname, INFO, "vhost peer closed\n"); - + if (ret == 0) { + VHOST_LOG_CONFIG(dev->ifname, INFO, "vhost peer closed\n"); return -1; } @@ -3010,6 +3007,14 @@ vhost_user_msg_handler(int vid, int fd) else msg_handler = NULL; + if (ret < 0) { + VHOST_LOG_CONFIG(dev->ifname, ERR, "vhost read message %s%s%sfailed\n", + msg_handler != NULL ? "for " : "", + msg_handler != NULL ? msg_handler->description : "", + msg_handler != NULL ? " " : ""); + return -1; + } + if (msg_handler != NULL && msg_handler->description != NULL) { if (request != VHOST_USER_IOTLB_MSG) VHOST_LOG_CONFIG(dev->ifname, INFO, -- David Marchand