[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3] ati-vga: check address before reading configuration bytes
From: |
Michael Tokarev |
Subject: |
Re: [PATCH v3] ati-vga: check address before reading configuration bytes (CVE-2020-13791) |
Date: |
Thu, 2 Jul 2020 10:54:01 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 |
[Please excuse me for top-posting, I want to preserve somewhat old context]
So, is this CVE-2020-13791 issue fixed by the fix for CVE-2020-13754,
by this commit:
https://git.qemu.org/?p=qemu.git;a=commit;h=5d971f9e672507210e77d020d89e0e89165c8fc9
?
Thanks,
/mjt
04.06.2020 15:00, Michael S. Tsirkin wrote:
> On Thu, Jun 04, 2020 at 01:56:45PM +0200, Philippe Mathieu-Daudé wrote:
>> On 6/4/20 1:49 PM, Michael S. Tsirkin wrote:
>>> On Thu, Jun 04, 2020 at 04:25:24PM +0530, P J P wrote:
>>>> From: Prasad J Pandit <pjp@fedoraproject.org>
>>>>
>>>> While reading PCI configuration bytes, a guest may send an
>>>> address towards the end of the configuration space. It may lead
>>>> to an OOB access issue. Add check to ensure 'address + size' is
>>>> within PCI configuration space.
>>>>
>>>> Reported-by: Ren Ding <rding@gatech.edu>
>>>> Reported-by: Hanqing Zhao <hanqing@gatech.edu>
>>>> Reported-by: Yi Ren <c4tren@gmail.com>
>>>> Suggested-by: BALATON Zoltan <balaton@eik.bme.hu>
>>>> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
>>>
>>> BTW, this only happens on unaligned accesses.
>>> And the IO memory region in question does not set valid.unaligned
>>> or .impl.unaligned.
>>>
>>> And the documentation says:
>>>
>>> - .valid.unaligned specifies that the *device being modelled* supports
>>> unaligned accesses; if false, unaligned accesses will invoke the
>>> appropriate bus or CPU specific behaviour.
>>>
>>> and
>>>
>>> - .impl.unaligned specifies that the *implementation* supports unaligned
>>> accesses; if false, unaligned accesses will be emulated by two aligned
>>> accesses.
>>>
>>> Is this then another case of a memory core bug which should have either
>>> failed the access or split it?
>>
>> Related:
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg695362.html
>> earlier comment:
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg694805.html
>
> Yea looks like more devices following documentation and memory core
> doing something else instead.
>
>>>
>>>> ---
>>>> hw/display/ati.c | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> Update v3: avoid modifying 'addr' variable
>>>> -> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00834.html
>>>>
>>>> diff --git a/hw/display/ati.c b/hw/display/ati.c
>>>> index 67604e68de..b4d0fd88b7 100644
>>>> --- a/hw/display/ati.c
>>>> +++ b/hw/display/ati.c
>>>> @@ -387,7 +387,9 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr,
>>>> unsigned int size)
>>>> val = s->regs.crtc_pitch;
>>>> break;
>>>> case 0xf00 ... 0xfff:
>>>> - val = pci_default_read_config(&s->dev, addr - 0xf00, size);
>>>> + if ((addr - 0xf00) + size <= pci_config_size(&s->dev)) {
>>>> + val = pci_default_read_config(&s->dev, addr - 0xf00, size);
>>>> + }
>>>> break;
>>>> case CUR_OFFSET:
>>>> val = s->regs.cur_offset;
>>>> --
>>>> 2.26.2
>>>
>
>
- Re: [PATCH v3] ati-vga: check address before reading configuration bytes (CVE-2020-13791),
Michael Tokarev <=