[PATCH] vhost/vringh: reject zero-length indirect descriptor tables

[PATCH] vhost/vringh: reject zero-length indirect descriptor tables

[Fang Xieyan]

move_to_indirect() accepts an indirect descriptor with a zero length,
setting desc_max to 0. __vringh_iov() then reads descs[0] before
checking the descriptor bounds, resulting in an out-of-bounds read.

Reject a zero-length indirect table in move_to_indirect() so the
caller returns -EINVAL before dereferencing the table. Also use the
converted length in the warning to report invalid lengths correctly
when the vring byte order differs from the CPU byte order.

Fixes: f87d0fbb5798 ("vringh: host-side implementation of virtio rings.")
Cc: stable@vger.kernel.org
Reviewed-by: Guanglei Zhu <zhugl3@xiaopeng.com>
Signed-off-by: Fang Xieyan <fangxy@xiaopeng.com>
---
 drivers/vhost/vringh.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
index 9066f9f12ba1..ce4f5a02c8d2 100644
--- a/drivers/vhost/vringh.c
+++ b/drivers/vhost/vringh.c
@@ -197,8 +197,8 @@ static int move_to_indirect(const struct vringh *vrh,
 	}
 
 	len = vringh32_to_cpu(vrh, desc->len);
-	if (unlikely(len % sizeof(struct vring_desc))) {
-		vringh_bad("Strange indirect len %u", desc->len);
+	if (unlikely(!len || len % sizeof(struct vring_desc))) {
+		vringh_bad("Strange indirect len %u", len);
 		return -EINVAL;
 	}
 
-- 
2.50.1

Re: [PATCH] vhost/vringh: reject zero-length indirect descriptor tables

[Michael S. Tsirkin]

On Wed, Oct 21, 2026 at 03:02:42PM +0800, Fang Xieyan wrote:
> move_to_indirect() accepts an indirect descriptor with a zero length,
> setting desc_max to 0. __vringh_iov() then reads descs[0] before
> checking the descriptor bounds, resulting in an out-of-bounds read.
> 
> Reject a zero-length indirect table in move_to_indirect() so the
> caller returns -EINVAL before dereferencing the table. Also use the
> converted length in the warning to report invalid lengths correctly
> when the vring byte order differs from the CPU byte order.
> 
> Fixes: f87d0fbb5798 ("vringh: host-side implementation of virtio rings.")
> Cc: stable@vger.kernel.org
> Reviewed-by: Guanglei Zhu <zhugl3@xiaopeng.com>
> Signed-off-by: Fang Xieyan <fangxy@xiaopeng.com>


Isn't this already addressed by
Subject: [PATCH v2] vringh: reject empty / undersized indirect descriptor tables
that you posted previously?

> ---
>  drivers/vhost/vringh.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
> index 9066f9f12ba1..ce4f5a02c8d2 100644
> --- a/drivers/vhost/vringh.c
> +++ b/drivers/vhost/vringh.c
> @@ -197,8 +197,8 @@ static int move_to_indirect(const struct vringh *vrh,
>  	}
>  
>  	len = vringh32_to_cpu(vrh, desc->len);
> -	if (unlikely(len % sizeof(struct vring_desc))) {
> -		vringh_bad("Strange indirect len %u", desc->len);
> +	if (unlikely(!len || len % sizeof(struct vring_desc))) {
> +		vringh_bad("Strange indirect len %u", len);
>  		return -EINVAL;
>  	}
>  
> -- 
> 2.50.1

Re: [PATCH] vhost/vringh: reject zero-length indirect descriptor tables

[Fang Xieyan]

Hi Michael,

Yes, same fix - sorry. The October 21 posting is a duplicate
of the v2 I posted on September 26:

https://lore.kernel.org/virtualization/20260926160755.21485-1-fangxy@xiaopeng.com/

I resent it as a new patch instead of a v3.

The !len form is equivalent to v2's len < sizeof(struct
vring_desc) check when combined with the modulo check -
zero is the only length below one descriptor that is also
a multiple of the descriptor size.

The diagnostic change is to pass the byte-order converted
len instead of the raw desc->len, so the reported length is
correct when the vring byte order differs from the CPU byte
order.

Would you prefer that I send a v3 on the original v2 thread
with this diagnostic correction, or should I drop the
October 21 posting and leave v2 as is?

Thanks,
Fang

Re: [PATCH] vhost/vringh: reject zero-length indirect descriptor tables

[Michael S. Tsirkin]

On Tue, Nov 03, 2026 at 11:29:35AM +0800, Fang Xieyan wrote:
> Hi Michael,
> 
> Yes, same fix - sorry. The October 21 posting is a duplicate
> of the v2 I posted on September 26:
> 
> https://lore.kernel.org/virtualization/20260926160755.21485-1-fangxy@xiaopeng.com/
> 
> I resent it as a new patch instead of a v3.
> 
> The !len form is equivalent to v2's len < sizeof(struct
> vring_desc) check when combined with the modulo check -
> zero is the only length below one descriptor that is also
> a multiple of the descriptor size.
> 
> The diagnostic change is to pass the byte-order converted
> len instead of the raw desc->len, so the reported length is
> correct when the vring byte order differs from the CPU byte
> order.
> 
> Would you prefer that I send a v3 on the original v2 thread
> with this diagnostic correction, or should I drop the
> October 21 posting and leave v2 as is?
> 
> Thanks,
> Fang

pls take a look at my tree, vhost branch. if you want any
changes made wrt that, pls let me know.

-- 
MST