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 49E3B41C30 for ; Tue, 7 Feb 2023 17:18:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 419A14021F; Tue, 7 Feb 2023 17:18:06 +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 E4C9A40151 for ; Tue, 7 Feb 2023 17:18:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675786684; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HuGpcRN/E9nO8P+sin6IJxYGb2gpKARs8QcX0g1w5ss=; b=Cb6J2CSxwA0FvQfmnQgMQWC+wiDfDt5eTByrrbVLFlAymbsy7OzD1vGH6h/+gnI07E4WVT ksYsmE4SHei+Q3M6OxVnfI9js2tMNeB//0+2S64QVx5RzD47iEueFdAJhFh+9L63vPWLkT 7KjXxOex8wsr9SustK3i6FIMK5bbXOY= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-589-Y6Rks0M1MaqW1hx9vdo5Cw-1; Tue, 07 Feb 2023 11:18:03 -0500 X-MC-Unique: Y6Rks0M1MaqW1hx9vdo5Cw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8740929ABA16; Tue, 7 Feb 2023 16:18:02 +0000 (UTC) Received: from [10.39.208.26] (unknown [10.39.208.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A968F401014C; Tue, 7 Feb 2023 16:18:01 +0000 (UTC) Message-ID: Date: Tue, 7 Feb 2023 17:18:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v2 1/2] vhost: fix possible FDs leak To: David Marchand Cc: dev@dpdk.org, chenbo.xia@intel.com, stable@dpdk.org References: <20230127165540.37863-1-maxime.coquelin@redhat.com> <20230127165540.37863-2-maxime.coquelin@redhat.com> From: Maxime Coquelin In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On 1/30/23 15:25, David Marchand wrote: > 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, > > It looks good to me. I'm squashing this with patch 1, adding you SoB. Thanks, Maxime