[PATCH v2] HID: bpf: Fix signedness bug in hid_bpf_hw_request

[PATCH v2] HID: bpf: Fix signedness bug in hid_bpf_hw_request

[Guangshuo Li]

hid_bpf_hw_request() clamps the return value of hid_hw_raw_request() to
the size of the caller-supplied buffer before copying data back to the
BPF buffer.

However, ret is signed while size is unsigned. If hid_hw_raw_request()
returns a negative error code, the comparison promotes ret to size_t.
This makes the negative value look like a very large positive value, so
the error is clamped to size. The following memcpy() then treats the
failed request as a successful transfer and copies stale data back to
the caller.

Handle negative return values before comparing ret with size and jump to
the common cleanup path on error. This preserves negative error codes
while still preventing oversized successful returns from overflowing
the caller-supplied buffer.

Fixes: 2b658c1c442e ("HID: bpf: prevent buffer overflow in hid_hw_request")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v2:
  - Handle negative return values before comparing the return length
    with the unsigned buffer size, as suggested by Emil Tsalapatis.
  - Use the common cleanup path for negative return values.

 drivers/hid/bpf/hid_bpf_dispatch.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index d0130658091b..520b8f56a514 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -445,12 +445,14 @@ hid_bpf_hw_request(struct hid_bpf_ctx *ctx, __u8 *buf, size_t buf__sz,
 					      reqtype,
 					      (u64)(long)ctx,
 					      true); /* prevent infinite recursions */
-
+	if (ret < 0)
+		goto done;
 	if (ret > size)
 		ret = size;
 	if (ret > 0)
 		memcpy(buf, dma_data, ret);
 
+done:
 	kfree(dma_data);
 	return ret;
 }
-- 
2.43.0

Re: [PATCH v2] HID: bpf: Fix signedness bug in hid_bpf_hw_request

[sashiko-bot]

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

Pre-existing issues:
- [High] Dereferencing ZERO_SIZE_PTR in hid_bpf_hw_request() when report length is 0, causing a kernel panic.
--

--- Patch [1]: [PATCH v2] HID: bpf: Fix signedness bug in hid_bpf_hw_request ---
commit 87da4183dd7e20066daec7a3b7c00194ac025c96
Author: Guangshuo Li <lgs201920130244@gmail.com>

HID: bpf: Fix signedness bug in hid_bpf_hw_request

This commit fixes a bug in hid_bpf_hw_request() where a negative return
value from hid_hw_raw_request() was improperly compared to an unsigned size,
causing the function to treat the failure as a successful transfer and
copy stale data back to the caller.

> diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
> index d0130658091b0..520b8f56a5146 100644
> --- a/drivers/hid/bpf/hid_bpf_dispatch.c
> +++ b/drivers/hid/bpf/hid_bpf_dispatch.c
> @@ -445,12 +445,14 @@ hid_bpf_hw_request(struct hid_bpf_ctx *ctx, __u8 *buf, size_t buf__sz,
>  					      reqtype,
>  					      (u64)(long)ctx,
>  					      true); /* prevent infinite recursions */

[Severity: High]
This is a pre-existing issue, but can this dereference ZERO_SIZE_PTR and cause
a kernel panic?

If hid_bpf_hw_request() is called with a buffer of size >= 1 for a HID device
report that has a report_len of 0, __hid_bpf_hw_check_params() will clamp
the size to 0:

drivers/hid/bpf/hid_bpf_dispatch.c:__hid_bpf_hw_check_params() {
    ...
	if (*buf__sz > report_len)
		*buf__sz = report_len;
    ...
}

When size is clamped to 0, kmemdup(buf, 0, GFP_KERNEL) allocates 0 bytes and
returns ZERO_SIZE_PTR (0x10). The check for !dma_data passes because
ZERO_SIZE_PTR is not NULL.

The code then evaluates dma_data[0] to pass the report ID to
hid_hw_raw_request(), which will dereference ZERO_SIZE_PTR at memory address
0x10 and crash the kernel. Should we add a check for size == 0 before calling
kmemdup()?

> -
> +	if (ret < 0)
> +		goto done;
>  	if (ret > size)
>  		ret = size;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713132608.1265541-1-lgs201920130244@gmail.com?part=1