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 6B36F41B81 for ; Mon, 30 Jan 2023 10:46:25 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 54B4D40EDE; Mon, 30 Jan 2023 10:46:25 +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 8EF1940C35 for ; Mon, 30 Jan 2023 10:46:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675071983; 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=RmVpcWUKqqOxNjz7i7ySNNwdxZZ5WDGKBubDtnz6NN4=; b=Vw5uNzVClwpq0bVgRR2r1ZYuygYQPKJefLmHmhqPZ2+dHvfTdn3TCeKC7Bqa4RtycMj6Qe W7GeFKjZf7nU6Ms610QtlREyWFuq2YK+lcTomHrDZ2VTVNX2J21CykVVvHAW28T4VRhDcG zeyYT7Rje4Wimc5xHAy17om5w/LWC8c= 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-61-fLa_qbo5M6u3YFuVnf3j-g-1; Mon, 30 Jan 2023 04:46:21 -0500 X-MC-Unique: fLa_qbo5M6u3YFuVnf3j-g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2B6EA29A9D40; Mon, 30 Jan 2023 09:46:21 +0000 (UTC) Received: from [10.39.208.22] (unknown [10.39.208.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4D00F400EAD6; Mon, 30 Jan 2023 09:46:20 +0000 (UTC) Message-ID: Date: Mon, 30 Jan 2023 10:46:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 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 Subject: Re: [PATCH v2 1/2] vhost: fix possible FDs leak In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 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/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. Any thoughts? Maxime