[PATCH v2] usbip: clear actual length after receive failure

[PATCH v2] usbip: clear actual length after receive failure

[Sung Byeongchan]

A USB/IP peer supplies actual_length in RET_SUBMIT. usbip_recv_xbuff()
rejects positive values larger than the URB transfer buffer, but stores the
u32 length in a signed int. Values with the top bit set therefore take the
size <= 0 success path and the VHCI gives the URB back with the
peer-controlled length still present.

usbfs completion consumers use urb->actual_length as an unsigned extent. On
review base e971f4f365bad, 0x80000000, 0x80000001, and 0xffffffff each
produced a KASAN out-of-bounds read with usbfs snooping enabled in three
fresh boots, both before the original patch and with its V1 applied.

Keep the transfer extent unsigned in usbip_recv_xbuff(), so the existing
transfer-buffer bound rejects positive and top-bit-set oversized values.
Also clear actual_length when receiving the transfer buffer fails. No
payload is valid on this error path, and zero prevents completion consumers
from reusing the rejected extent.

The V2 kernel completed 42 fresh-boot cases across normal, short,
positive oversized, high-bit, and both snoop modes without KASAN.
Rejected completions were normalized to -EPROTO and actual_length zero;
following valid URBs, reconnect/recovery, and disconnect cleanup remained
functional.

The demonstrated impact is a kernel out-of-bounds read and possible crash
from an untrusted USB/IP peer. Information disclosure, a controlled write,
RCE, and LPE were not demonstrated.

This issue was found through manual source inspection assisted by an
AI/LLM, then evaluated with local production-path dynamic validation.

Fixes: aabb5b833872 ("usbip: Fix error path of vhci_recv_ret_submit()")
Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>
---
 drivers/usb/usbip/usbip_common.c | 2 +-
 drivers/usb/usbip/vhci_rx.c      | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
index 100f8920624bb..e3cfe7ccd0455 100644
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -831,7 +831,7 @@ int usbip_recv_xbuff(struct usbip_device *ud, struct urb *urb)
 	struct scatterlist *sg;
 	int ret = 0;
 	int recv;
-	int size;
+	unsigned int size;
 	int copy;
 	int i;
 
diff --git a/drivers/usb/usbip/vhci_rx.c b/drivers/usb/usbip/vhci_rx.c
index a678e7c898375..741107a964660 100644
--- a/drivers/usb/usbip/vhci_rx.c
+++ b/drivers/usb/usbip/vhci_rx.c
@@ -79,6 +79,7 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev,
 	/* recv transfer buffer */
 	if (usbip_recv_xbuff(ud, urb) < 0) {
 		urb->status = -EPROTO;
+		urb->actual_length = 0;
 		goto error;
 	}
 
-- 
2.43.0

Re: [PATCH v2] usbip: clear actual length after receive failure

[sashiko-bot]

> A USB/IP peer supplies actual_length in RET_SUBMIT. usbip_recv_xbuff()
> rejects positive values larger than the URB transfer buffer, but stores the
> u32 length in a signed int. Values with the top bit set therefore take the
> size <= 0 success path and the VHCI gives the URB back with the
> peer-controlled length still present.
> 
> usbfs completion consumers use urb->actual_length as an unsigned extent. On
> review base e971f4f365bad, 0x80000000, 0x80000001, and 0xffffffff each
> produced a KASAN out-of-bounds read with usbfs snooping enabled in three
> fresh boots, both before the original patch and with its V1 applied.
> 
> Keep the transfer extent unsigned in usbip_recv_xbuff(), so the existing
> transfer-buffer bound rejects positive and top-bit-set oversized values.
> Also clear actual_length when receiving the transfer buffer fails. No
> payload is valid on this error path, and zero prevents completion consumers
> [ ... ]
> This issue was found through manual source inspection assisted by an
> AI/LLM, then evaluated with local production-path dynamic validation.
> 
> Fixes: aabb5b833872 ("usbip: Fix error path of vhci_recv_ret_submit()")
> Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261101111551.1785593-1-tjdqudcks0424@naver.com?part=1