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 31BEEA00C4; Wed, 28 Sep 2022 18:03:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CEA154113C; Wed, 28 Sep 2022 18:03:29 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id E9F32410FA for ; Wed, 28 Sep 2022 18:03:27 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6145B5C0112; Wed, 28 Sep 2022 12:03:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 28 Sep 2022 12:03:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1664381005; x= 1664467405; bh=lG0x86VB9LOfgEYEw6/EndKNSjSOIxPbrgGfk/DL6j4=; b=T lgVJiDVS3bWmHGpBbzb/qt6u2312xLgHkFQpfVK2Lnh1dzhgbmgeKFh3Jxsr5JW9 RevU3PkQuVpBs5wRMyj7kuM9RZdK93FwdGM2F35nCQ0mqvusrmGUinY25+2BpLFF Qy9+tQZvrky/5XjLK2u8JBK7TVSsvAmV4rfHgAiNGXxjS2CMbytjumyhqLAvblS+ l1IiNlGy5JTl7D3Ash1nfsXF1WXP6XQ/v3jrBrpK44Rz31kNXJC249RrNHUeFmPd LEoutLdsRc4M7utnyr6ASaGXxwSYXic+NfBHJNj9sddFyNljVMgqk3eUo+tYW347 qD8Uo4wUXg8/crSzabTCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664381005; x= 1664467405; bh=lG0x86VB9LOfgEYEw6/EndKNSjSOIxPbrgGfk/DL6j4=; b=P mt0U7UEaBgOXgPDvP6u+MhwKwAnzZt+HuyVCURW+HNPuV/XxXB9WaKmdezOlipkl pZbyWhe7R16kuCTZ/XskcbhdbLTRrnExnUOT454MvCkok7vagWmA4d4FL4erXZUx 3SA2Bvf9hhqeFTCDvYwfAWRY4DrRdkwWDJuNM7YthU4fb/KYT7qf3IE6tPdu1yZm V7KwWWEYlc48LVaoBM+DDiMj4MnAkIgs+jdOXwadjMtrmTn0XgZiBIgIBzF2cQmK CVWdqnM5CEPsWJcISZlCQW2VMBxhJUvR0lglVKwi3UUJY1tzqr16PaeDWUh9yv4m gkymvccpACSyDGLhUElTQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegkedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 28 Sep 2022 12:03:23 -0400 (EDT) From: Thomas Monjalon To: Claudio Fontana Cc: Maxime Coquelin , Chenbo Xia , dev@dpdk.org Subject: Re: [PATCH v3 1/2] vhost: check for nr_vec == 0 in desc_to_mbuf, mbuf_to_desc Date: Wed, 28 Sep 2022 18:03:21 +0200 Message-ID: <5662486.1B3tZ46Xf9@thomas> In-Reply-To: <77f63478-88d1-01b2-0cdd-c93289bd42a6@suse.de> References: <20220802004938.23670-1-cfontana@suse.de> <228bf109-57c2-91f0-ab2c-6ac92d688781@redhat.com> <77f63478-88d1-01b2-0cdd-c93289bd42a6@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 28/09/2022 17:21, Claudio Fontana: > On 9/28/22 16:37, Maxime Coquelin wrote: > > The title should be reworded, maybe something like below? > > "vhost: fix possible out of bound access in buffer vectors" > > possible, I leave it to you and other maintainers here now to figure out. Maxime is suggesting a reword to you for your next version. > > On 8/2/22 02:49, Claudio Fontana wrote: [...] > >> 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. What are the "multiple occasions"? Is there an entry in bugs.dpdk.org? [...] > > I'm going to try to reproduce the issue, but I'm not sure I will > > succeed. Could you please share the Vhost logs when the issue is > > reproduced and you face the crash? > > With vacations and lab work it's unlikely anything can be done from my side for the next 2-3 weeks. We can probably wait 3 more weeks. > This issue has been reported multiple times from multiple telco customers for about a year, it's all over the mailing lists > between ovs, dpdk and qemu, with all the details. What was the reply on the DPDK mailing list? Any link? > Something in the governance of these Open Source projects is clearly not working right, probably too much inward-focus between a small number of companies, but I digress. Contributors to DPDK are from multiple companies, but I agree we may need more help. Thank you for bringing your help with this fix. > I think Chenbo Xia already knows the context, and I suspect this is now considered a "security issue". The problem is, the information about all of this has been public already for a year. OK > I will again repost how to reproduce here: Thanks it helps to have all infos in the same place. [...] > > It is a fix, so it should contains the Fixes tag, and also cc > > stable@dpdk.org. > > After one year, it is time for Redhat and Intel or whatever the governance of this project is, The DPDK governance is not owned by any company. If you think there is an issue in a decision, you can alert the Technical Board at techboard@dpdk.org. > to mention if there is any intention to fix this or not, > before I or anyone else at SUSE will invest any more of our time and efforts here. I don't understand why we would not fix any issue. I think the project is quite dynamic and fixing issues, I am sorry if you have a different opinion. > Any tags you need you can add as required. It would be nice to add the tags as suggested in the next version. The most important would be to know where the issue comes from. If you can identify the original commit introducing the bug, you can mark it with: Fixes: ("") This way, maintainers and users know where it should be backported. If any question, feel free to ask, we are here to help. Thanks for the effort