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 C2AFB41B81; Mon, 30 Jan 2023 10:46:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 85BFF40EE2; Mon, 30 Jan 2023 10:46:26 +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 600A040EE2 for ; Mon, 30 Jan 2023 10:46:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675071984; 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=KWZ5qrrj7XDVdZMTF4Nwy9LjO6KGsRXJfGUbk3PnQLddGXPurG6Ua7JuQYr8X+to68qJ3x ui3tAQhsHyhbcLLGsTTaPIgyXS/g0H0k51JbFVg7xrrNk3ugH9g+M1uIk0U4u9+3NKdhll Bi2mKYix1+51vBFvYdmaf5RBwidVSaQ= 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: 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 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