On Wed, 27 Jul 2022 at 15:11, Daniel Henrique Barboza <danielhb...@gmail.com> wrote: > > > > On 7/26/22 15:24, Peter Maydell wrote: > > On Tue, 26 Jul 2022 at 19:23, Peter Maydell <peter.mayd...@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
