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 ECC04A00C5; Wed, 2 Nov 2022 11:34:54 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D212E40693; Wed, 2 Nov 2022 11:34:54 +0100 (CET) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by mails.dpdk.org (Postfix) with ESMTP id 5CA7040223 for ; Wed, 2 Nov 2022 11:34:54 +0100 (CET) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 35AA6336B1; Wed, 2 Nov 2022 10:34:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1667385294; h=from:from:reply-to: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=3dEMCGMBpKcSMyFN+P4fr5hhC+8nQjPpmvOhDQvrYIE=; b=GKac3VrUBatYTAXV/hTY+jnjWCjKvI0RjIX46Y6XJMOkV0cTqSCke9lQxqrw1HeqVbKeBT fsErRvF/HWrlkZfBfZHIOoxH3To21m0XtQEeUACdtUTYoSudrcmax+ICP4+20vCqlH+NyF ZgtxDYZHvYCvPQhAVMDO0pkX+e1onak= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1667385294; h=from:from:reply-to: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=3dEMCGMBpKcSMyFN+P4fr5hhC+8nQjPpmvOhDQvrYIE=; b=6HbAQyRpdEhudIW0mbdm0OdICZpRUz9A62ws8acR6WloXrQNXue0XhS18AxOqX6pOIStQn /chEJneBrT/xYVAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 1728D13AE0; Wed, 2 Nov 2022 10:34:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id D2P8A85HYmPQVAAAMHmgww (envelope-from ); Wed, 02 Nov 2022 10:34:54 +0000 Message-ID: <0e983180-0cbb-c20f-6937-e6384d29d099@suse.de> Date: Wed, 2 Nov 2022 11:34:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v3 1/2] vhost: check for nr_vec == 0 in desc_to_mbuf, mbuf_to_desc Content-Language: en-US To: Maxime Coquelin , Chenbo Xia Cc: dev@dpdk.org References: <20220802004938.23670-1-cfontana@suse.de> <20220802004938.23670-2-cfontana@suse.de> <9a8f3fb4-44d1-f437-7065-317bf34748b4@redhat.com> From: Claudio Fontana In-Reply-To: <9a8f3fb4-44d1-f437-7065-317bf34748b4@redhat.com> Content-Type: text/plain; charset=UTF-8 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 10/5/22 17:06, Maxime Coquelin wrote: > > > On 8/2/22 02:49, Claudio Fontana wrote: >> in virtio_dev_split we cannot currently call desc_to_mbuf with >> nr_vec == 0, or we end up trying to rte_memcpy from a source address >> buf_vec[0] that is an uninitialized stack variable. >> >> Improve this in general by having desc_to_mbuf and mbuf_to_desc >> return -1 when called with an invalid nr_vec == 0, which should >> fix any other instance of this problem. >> >> This should fix errors that have been reported in multiple occasions >> from telcos to the DPDK, OVS and QEMU projects, as this affects in >> particular the openvswitch/DPDK, QEMU vhost-user setup when the >> guest DPDK application abruptly goes away via SIGKILL and then >> reconnects. >> >> The back trace looks roughly like this, depending on the specific >> rte_memcpy selected, etc, in any case the "src" parameter is garbage >> (in this example containing 0 + dev->host_hlen(12 = 0xc)). >> >> Thread 153 "pmd-c88/id:150" received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7f64e5e6b700 (LWP 141373)] >> rte_mov128blocks (n=2048, src=0xc , >> dst=0x150da4480) at ../lib/eal/x86/include/rte_memcpy.h:384 >> (gdb) bt >> 0 rte_mov128blocks (n=2048, src=0xc, dst=0x150da4480) >> 1 rte_memcpy_generic (n=2048, src=0xc, dst=0x150da4480) >> 2 rte_memcpy (n=2048, src=0xc, dst=) >> 3 sync_fill_seg >> 4 desc_to_mbuf >> 5 virtio_dev_tx_split >> 6 virtio_dev_tx_split_legacy >> 7 0x00007f676fea0fef in rte_vhost_dequeue_burst >> 8 0x00007f6772005a62 in netdev_dpdk_vhost_rxq_recv >> 9 0x00007f6771f38116 in netdev_rxq_recv >> 10 0x00007f6771f03d96 in dp_netdev_process_rxq_port >> 11 0x00007f6771f04239 in pmd_thread_main >> 12 0x00007f6771f92aff in ovsthread_wrapper >> 13 0x00007f6771c1b6ea in start_thread >> 14 0x00007f6771933a8f in clone >> >> Tested-by: Claudio Fontana >> Signed-off-by: Claudio Fontana >> --- >> lib/vhost/virtio_net.c | 11 ++++++++--- >> 1 file changed, 8 insertions(+), 3 deletions(-) > > This patch is also no more necessary since CVE-2022-2132 has been fixed. > Latests LTS versions and upstream main branch contain the fixes: > > dc1516e260a0 ("vhost: fix header spanned across more than two descriptors") > 71bd0cc536ad ("vhost: discard too small descriptor chains") > > desc_to_mbuf callers now check that the descriptors are at least the > size of the virtio_net header, so nr_vec cannot be 0 in desc_to_mbuf. > > Since I cannot reproduce, if you are willing to try please let us know > the results. > > Maxime > Hello Maxime, which versions of DPDK did you get to test in the guest? The problem seems to be easier to reproduce when DPDK 16.x is in the guest. The guest OS where the problem was encountered in the field is "Ubuntu 16.04", but we were able to reproduce this also in our lab with ubuntu20.04. For reproduction we have used a few network cards, mainly Intel X520. I'll let you know our results as I have them. Thanks, CLaudio