[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: Philippe Mathieu-Daudé
Subject: Re: [PATCH] hw/display/ati_2d: Fix buffer overflow in ati_2d_blt (CVE-2021-3638)
Date: Thu, 9 Sep 2021 11:32:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 9/9/21 11:16 AM, Mauro Matteo Cascella wrote:
> 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.)?

I just posted a suggestion as RFC but forgot to Cc you:
"security: Introduce qemu_security_policy_taint() API"
In particular for the ati-vga device:

reply via email to

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