[Top][All Lists]

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

Re: [RFC 1/2] hw/ppc/ppc440_uc: Initialize length passed to cpu_physical

From: Daniel Henrique Barboza
Subject: Re: [RFC 1/2] hw/ppc/ppc440_uc: Initialize length passed to cpu_physical_memory_map()
Date: Wed, 27 Jul 2022 11:11:11 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

On 7/26/22 15:24, Peter Maydell wrote:
On Tue, 26 Jul 2022 at 19:23, Peter Maydell <peter.maydell@linaro.org> wrote:

In dcr_write_dma(), there is code that uses cpu_physical_memory_map()
to implement a DMA transfer.  That function takes a 'plen' argument,
which points to a hwaddr which is used for both input and output: the
caller must set it to the size of the range it wants to map, and on
return it is updated to the actual length mapped. The dcr_write_dma()
code fails to initialize rlen and wlen, so will end up mapping an
unpredictable amount of memory.

Initialize the length values correctly, and check that we managed to
map the entire range before using the fast-path memmove().

This was spotted by Coverity, which points out that we never
initialized the variables before using them.

Fixes: Coverity CID 1487137

Also CID 1487150 (it reports the wlen and rlen issues separately).

I amended in tree:

    Fixes: Coverity CID 1487137, 1487150

I also believe that this Coverity fix isn't dependent on patch 2, which
apparently will take longer to get reviewed, so it's fine to take it



Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

-- PMM

reply via email to

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