aboutsummaryrefslogtreecommitdiff
path: root/scripts/qapi/common.py
diff options
context:
space:
mode:
authorAlexander Bulekov <alxndr@bu.edu>2021-07-13 11:00:34 -0400
committerAlexander Bulekov <alxndr@bu.edu>2021-09-01 07:33:13 -0400
commitaf16990a1b3aac7a32a58cd4e3509e9e4d44fe69 (patch)
tree773e9e22ec610ca77470702c75d54434342e73dd /scripts/qapi/common.py
parentec397e90d21269037280633b6058d1f280e27667 (diff)
downloadqemu-af16990a1b3aac7a32a58cd4e3509e9e4d44fe69.zip
qemu-af16990a1b3aac7a32a58cd4e3509e9e4d44fe69.tar.gz
qemu-af16990a1b3aac7a32a58cd4e3509e9e4d44fe69.tar.bz2
fuzz: fix sparse memory access in the DMA callback
The code mistakenly relied on address_space_translate to store the length remaining until the next memory-region. We care about this because when there is RAM or sparse-memory neighboring on an MMIO region, we should only write up to the border, to prevent inadvertently invoking MMIO handlers within the DMA callback. However address_space_translate_internal only stores the length until the end of the MemoryRegion if memory_region_is_ram(mr). Otherwise the *len is left unmodified. This caused some false-positive issues, where the fuzzer found a way to perform a nested MMIO write through a DMA callback on an [address, length] that started within sparse memory and spanned some device MMIO regions. To fix this, write to sparse memory in small chunks of memory_access_size (similar to the underlying address_space_write code), which will prevent accidentally hitting MMIO handlers through large writes. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Diffstat (limited to 'scripts/qapi/common.py')
0 files changed, 0 insertions, 0 deletions