Am 02.11.2018 um 02:22 hat Li Qiang geschrieben: > Currently, the nvme_cmb_ops mr doesn't check the addr and size. > This can lead an oob access issue. This is triggerable in the guest. > Add check to avoid this issue. > > Fixes CVE-2018-16847. > > Reported-by: Li Qiang <liq...@gmail.com> > Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> > Signed-off-by: Li Qiang <liq...@gmail.com> > --- > hw/block/nvme.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/hw/block/nvme.c b/hw/block/nvme.c > index fc7dacb..d097add 100644 > --- a/hw/block/nvme.c > +++ b/hw/block/nvme.c > @@ -1175,6 +1175,10 @@ static void nvme_cmb_write(void *opaque, hwaddr addr, > uint64_t data, > unsigned size) > { > NvmeCtrl *n = (NvmeCtrl *)opaque; > + > + if (addr + size > NVME_CMBSZ_GETSIZE(n->bar.cmbsz)) {
What prevents a guest from moving the device to the end of the address space and causing an integer overflow in addr + size? If this happens, we still have .max_access_size = 8. The next question is then, is NVME_CMBSZ_GETSIZE guaranteed to be at least 8? I suppose yes, but do we want to rely on this for security? Kevin