Re: [PATCH] vhost: reject zero-size IOTLB INVALIDATE

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch adds a zero-size IOTLB INVALIDATE check to the generic vhost handler but completely misses the vDPA-specific handler, leaving vDPA endpoints vulnerable to the IOTLB wipe bug.
- [High] The patch prevents `msg->size == 0` but fails to check for integer overflow when `msg->size` is extremely large. This causes `last` to wrap around, creating an inverted interval that incorrectly deletes unrelated IOTLB entries.
--

--- Patch [1]: [PATCH] vhost: reject zero-size IOTLB INVALIDATE ---
commit a0b9048f6eadbd7dc5629192fc48fcb0eb48ce7f
Author: xiongweimin <xiongweimin@kylinos.cn>
vhost: reject zero-size IOTLB INVALIDATE

This commit adds a check to reject VHOST_IOTLB_INVALIDATE messages with a size
of 0 in vhost_process_iotlb_msg(). This prevents an underflow calculation
that would otherwise pass U64_MAX as the end of the range, incorrectly wiping
the entire IOTLB.

> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 4c525b3e16ead..5d15fc41a3e98 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1657,6 +1657,10 @@ static int vhost_process_iotlb_msg(struct vhost_dev *dev, u32 asid,
>  			ret = -EFAULT;
>  			break;
>  		}
> +		if (!msg->size) {
> +			ret = -EINVAL;
> +			break;
> +		}

[Severity: High]
This isn't a bug introduced by this patch, but does the vDPA-specific handler
also need this zero-size check?

Looking at vhost_vdpa_process_iotlb_msg() in drivers/vhost/vdpa.c, it seems
to bypass this generic handler and processes the INVALIDATE message directly:

drivers/vhost/vdpa.c:vhost_vdpa_process_iotlb_msg() {
    ...
	case VHOST_IOTLB_INVALIDATE:
		vhost_vdpa_unmap(v, iotlb, msg->iova, msg->size);
		break;
    ...
}

If a userspace application sends an INVALIDATE message with msg->size == 0
and msg->iova == 0, vhost_vdpa_unmap() computes the last boundary as
iova + size - 1, which underflows to U64_MAX and could delete the entire map.

A similar underflow might occur if an IOTLB UPDATE mapping fails in
vhost_vdpa_va_map(). It calls vhost_vdpa_unmap(v, iotlb, iova, map_iova - iova)
which would pass a size of 0 if it fails on the first iteration.

Could this leave vDPA endpoints vulnerable to the same IOTLB wipe bug?

>  		vhost_vq_meta_reset(dev);
>  		vhost_iotlb_del_range(dev->iotlb, msg->iova,
>  				      msg->iova + msg->size - 1);

[Severity: High]
This is a pre-existing issue, but could this calculation overflow u64 and
create an inverted interval?

If a userspace application provides a large size (for example,
msg->iova = 0x1000 and msg->size = U64_MAX), msg->iova + msg->size - 1 will
overflow and wrap around to 0xFFE.

Unlike vhost_iotlb_add_range_ctx(), vhost_iotlb_del_range() in
drivers/vhost/iotlb.c doesn't seem to validate that start <= last before
querying the interval tree:

drivers/vhost/iotlb.c:vhost_iotlb_del_range() {
	struct vhost_iotlb_map *map;

	while ((map = vhost_iotlb_itree_iter_first(&iotlb->root,
						   start, last)))
		vhost_iotlb_map_free(iotlb, map);
}

The interval tree overlap check evaluates to true for any existing interval
that spans the inverted gap, which could cause valid, unrelated IOTLB entries
to be incorrectly deleted.

Does this need an upper-bound overflow check?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716030236.124322-1-xiongwm2026@163.com?part=1