On Thu, Dec 23, 2021 at 10:58:14AM +0100, Mauro Matteo Cascella wrote: > Hi, > > On Wed, Dec 22, 2021 at 9:52 PM Michael S. Tsirkin <m...@redhat.com> wrote: > > > > On Wed, Dec 22, 2021 at 09:27:51PM +0100, Philippe Mathieu-Daudé wrote: > > > On Wed, Dec 22, 2021 at 9:20 PM Michael S. Tsirkin <m...@redhat.com> > > > wrote: > > > > On Wed, Dec 22, 2021 at 08:19:41PM +0100, Philippe Mathieu-Daudé wrote: > > > > > +Mauro & Alex > > > > > > > > > > On 12/21/21 15:48, Michael S. Tsirkin wrote: > > > > > > When bus is looked up on a pci write, we didn't > > > > > > validate that the lookup succeeded. > > > > > > Fuzzers thus can trigger QEMU crash by dereferencing the NULL > > > > > > bus pointer. > > > > > > > > > > > > Fixes: b32bd763a1 ("pci: introduce acpi-index property for PCI > > > > > > device") > > > > > > Cc: "Igor Mammedov" <imamm...@redhat.com> > > > > > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/770 > > > > > > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > > > > > > > > > > It seems this problem is important enough to get a CVE assigned. > > > > > > > > Guest root can crash guest. > > > > I don't see why we would assign a CVE. > > > > > > Well thinking about downstream distributions, if there is a CVE assigned, > > > it helps them to have it written in the commit. Maybe I am mistaken. > > > > > > Unrelated but it seems there is a coordination problem with the > > > qemu-security@ list, > > > if this isn't a security issue, why was a CVE requested? > > > > Right. I don't think a priveleged user crashing VM warrants a CVE, > > it can just halt a CPU or whatever. Just cancel the CVE request pls. > > While I agree with you that this is kind of borderline and I expressed > similar concerns in the past, I was told that: > > 1) root guest users are not necessarily trustworthy (from the host > perspective). > 2) NULL pointer deref and similar issues caused by an > ill-handled/error condition are CVE worthy, even if triggered by root. > 3) In other cases, DoS triggered by root is not a security issue > because it's an expected behavior and not an ill-handled/error > condition (think of assert failures, for example). > > In other words, "ill-handled condition" is the crucial factor that > makes a bug CVE worthy or not.
I guess the point is that a downstream might have a slightly different code path where it would be more serious ... OK then, not a big deal for me. So what's the CVE # then? > +Prasad, can you shed some light on this? Is my understanding correct? > > Also, please note that we regularly get CVE requests for bugs like > this and many CVEs have been assigned in the past. Of course that > doesn't mean we can't change things going forward, but I think we > should make it clear (probably here: > https://www.qemu.org/docs/master/system/security.html) that these > kinds of bugs are not eligible for CVE assignment. That would be good, yes. > > > > > Mauro, please update us when you get the CVE number. > > > > > Michael, please amend the CVE number before committing the fix. > > > > > > > > > > FWIW Paolo asked every fuzzed bug reproducer to be committed > > > > > as qtest, see tests/qtest/fuzz*c. Alex has a way to generate > > > > > reproducer in plain C. > > > > > > > > > > Regards, > > > > > > > > > > Phil. > > > > > > > > -- > Mauro Matteo Cascella > Red Hat Product Security > PGP-Key ID: BB3410B0