[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-ppc
Subject:    Re: [RFC 1/2] hw/ppc/ppc440_uc: Initialize length passed to cpu_physical_memory_map()
From:       Peter Maydell <peter.maydell () linaro ! org>
Date:       2022-07-28 9:43:47
Message-ID: CAFEAcA8r-XQHyoJvbsPzv4eD0=Z9wcZQXarW3VaPGr1W_Y7q_w () mail ! gmail ! com
[Download RAW message or body]

On Wed, 27 Jul 2022 at 15:11, Daniel Henrique Barboza
<danielhb413@gmail.com> wrote:
>
>
>
> 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
> now.

Correct, and thank you.

-- PMM

[prev in list] [next in list] [prev in thread] [next in thread]