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

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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"
https://lore.kernel.org/qemu-devel/20210908232024.2399215-1-philmd@redhat.com/
In particular for the ati-vga device:
https://lore.kernel.org/qemu-devel/20210908232024.2399215-8-philmd@redhat.com/