From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: Fix PCI header check on device assignment Date: Wed, 06 Jun 2012 13:18:09 +0200 Message-ID: <4FCF3C71.2040601@siemens.com> References: <4FCDC54B.1020605@siemens.com> <1338916415.23475.223.camel@bling.home> <4FCF3B27.7050600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alex Williamson , Marcelo Tosatti , kvm , "vedun@ispras.ru" To: Avi Kivity Return-path: Received: from david.siemens.de ([192.35.17.14]:22680 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752850Ab2FFLSf (ORCPT ); Wed, 6 Jun 2012 07:18:35 -0400 In-Reply-To: <4FCF3B27.7050600@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-06-06 13:12, Avi Kivity wrote: > On 06/05/2012 08:13 PM, Alex Williamson wrote: >> On Tue, 2012-06-05 at 10:37 +0200, Jan Kiszka wrote: >>> The masking was wrong (must have been 0x7f), and there is no need to >>> re-read the value as pci_setup_device already does this for us. >> >> The intent was to mask off the multifunction bit from header_type, but >> the implementation is clearly wrong. hdr_type does both. Thanks >> >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43339 >>> Signed-off-by: Jan Kiszka >> >> Acked-by: Alex Williamson > > From your comment in the bugzilla entry I conclude that there is no need > to get this into 3.5. is this correct? As I asses this (and I think Alex meant the same), this is not a critical fix or even a security issue, just a (so far broken) safety belt for users that are privileged anyway. Also, there were no valid devices accidentally excluded due to the bug. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux