[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] hw/display/ati_2d: Fix buffer overflow in ati_2d_blt (CVE-20

From: Mauro Matteo Cascella
Subject: Re: [PATCH] hw/display/ati_2d: Fix buffer overflow in ati_2d_blt (CVE-2021-3638)
Date: Thu, 9 Sep 2021 11:16:41 +0200

On Tue, Sep 7, 2021 at 8:22 AM Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> On 9/7/21 7:38 AM, Philippe Mathieu-Daudé wrote:
> > On 9/6/21 9:52 PM, BALATON Zoltan wrote:
> >> I don't think assigning a CVE to a bug that is in an experimental and
> >> largely unused part and happens when one enables debug code really worth
> >> the hassle, this could be handled as a normal bug. As long as the
> >
> > CVE assignment can happens outside of QEMU community, we try to make it
> > clear what is the "security boundary" but researchers filling CVEs
> > might not understand it well.
> BTW see commit b317006a3f1 ("docs/secure-coding-practices: Describe how
> to use 'null-co' block driver") which is related to your suggestion.

I agree we can avoid assigning CVEs to ati-vga and similar
experimental devices that are not intended to be used in production,
even if they fall under the virtualization use case. Maybe we can
improve the documentation
(https://qemu-project.gitlab.io/qemu/system/security.html) to clearly
state that some devices are not security supported? Would it be
possible/feasible to get a list of such devices? Or maybe the other
way around, document the list of devices that are undeniably security
supported (e.g., virtio*, *hci, e1000, etc.)?

Mauro Matteo Cascella
Red Hat Product Security
PGP-Key ID: BB3410B0

reply via email to

[Prev in Thread] Current Thread [Next in Thread]