On Wed, May 04, 2022 at 03:40:48PM +0800, Xie Yongji wrote: > +static int vduse_queue_update_vring(VduseVirtq *vq, uint64_t desc_addr, > + uint64_t avail_addr, uint64_t used_addr) > +{ > + struct VduseDev *dev = vq->dev; > + uint64_t len; > + > + len = sizeof(struct vring_desc); > + vq->vring.desc = iova_to_va(dev, &len, desc_addr); > + assert(len == sizeof(struct vring_desc)); > + > + len = sizeof(struct vring_avail); > + vq->vring.avail = iova_to_va(dev, &len, avail_addr); > + assert(len == sizeof(struct vring_avail)); > + > + len = sizeof(struct vring_used); > + vq->vring.used = iova_to_va(dev, &len, used_addr); > + assert(len == sizeof(struct vring_used));
Can these assertions be triggered by a malicious virtio driver? For example, if a guest is accessing this device, will the vDPA/VDUSE kernel code forward the address to QEMU without validation? If yes, then it's necessary to return an error here instead of aborting. A qemu-storage-daemon process might contain multiple VDUSE exports and an error in one export shouldn't kill the entire process. I haven't audited the code, but this is a general issue: if vDPA/VDUSE kernel code forwards untrusted inputs to us then we cannot abort or crash. Usually the kernel is trusted by userspace but maybe not in this case since it may just forward inputs from a malicious VIRTIO driver?
signature.asc
Description: PGP signature