[PATCH] HID: picolcd: prevent NULL pointer dereference in picolcd_send_and_wait()

[PATCH] HID: picolcd: prevent NULL pointer dereference in picolcd_send_and_wait()

[Georgiy Osokin]

In picolcd_send_and_wait(), an integer overflow of the signed loop counter
'k' can theoretically lead to a NULL pointer dereference of 'raw_data'.
If the loop executes more than INT_MAX times, 'k' becomes negative,
making the condition 'k < size' true even when 'size' is 0.

Change the type of 'k' to 'unsigned int' to prevent the overflow and
eliminate the out-of-bounds access.

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.

Fixes: fabdbf2 ("HID: picoLCD: split driver code")
Signed-off-by: Georgiy Osokin <g.osokin@auroraos.dev>

---
 drivers/hid/hid-picolcd_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
index 2cc01e1bc1a8..d73e97c8b853 100644
--- a/drivers/hid/hid-picolcd_core.c
+++ b/drivers/hid/hid-picolcd_core.c
@@ -72,7 +72,8 @@ struct picolcd_pending *picolcd_send_and_wait(struct hid_device *hdev,
 	struct picolcd_pending *work;
 	struct hid_report *report = picolcd_out_report(report_id, hdev);
 	unsigned long flags;
-	int i, j, k;
+	int i, j;
+	unsigned int k;
 
 	if (!report || !data)
 		return NULL;
-- 
2.50.1

Re: [PATCH] HID: picolcd: prevent NULL pointer dereference in picolcd_send_and_wait()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Pre-existing sleeping in atomic context due to calling `hid_hw_request()` while holding a spinlock.
- [Medium] Unnecessary fix for an impossible scenario introducing a latent API vulnerability.
--

commit 26db02d94328ec65757bbf69ad49450f8c2b4f46
Author: Georgiy Osokin <g.osokin@auroraos.dev>

HID: picolcd: prevent NULL pointer dereference in picolcd_send_and_wait()

This commit changes the loop counter k to an unsigned int in
picolcd_send_and_wait(). The stated goal is to prevent an integer overflow
and a resulting out-of-bounds access.

> In picolcd_send_and_wait(), an integer overflow of the signed loop counter
> 'k' can theoretically lead to a NULL pointer dereference of 'raw_data'.
> If the loop executes more than INT_MAX times, 'k' becomes negative,
> making the condition 'k < size' true even when 'size' is 0.

Is this scenario actually possible? The HID core explicitly limits
report->maxfield to 256 (HID_MAX_FIELDS) and report->field[i]->report_count
to 12288 (HID_MAX_USAGES).

The maximum possible value for the loop counter k is 3,145,728, which
would not overflow a 32-bit signed integer.

> diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
> index 2cc01e1bc1a84..d73e97c8b853e 100644
> --- a/drivers/hid/hid-picolcd_core.c
> +++ b/drivers/hid/hid-picolcd_core.c
> @@ -72,7 +72,8 @@ struct picolcd_pending *picolcd_send_and_wait(struct hid_device *hdev,
>  	struct picolcd_pending *work;
>  	struct hid_report *report = picolcd_out_report(report_id, hdev);
>  	unsigned long flags;
> -	int i, j, k;
> +	int i, j;
> +	unsigned int k;
>  
>  	if (!report || !data)
>  		return NULL;

[ ... ]

Does changing k to an unsigned int introduce a latent vulnerability here?

drivers/hid/hid-picolcd_core.c:picolcd_send_and_wait() {
    ...
    for (i = k = 0; i < report->maxfield; i++)
        for (j = 0; j < report->field[i]->report_count; j++) {
            hid_set_field(report->field[i], j, k < size ? raw_data[k] : 0);
    ...
}

Because the size parameter passed to picolcd_send_and_wait() is still a
signed int, the condition k < size causes an implicit signed-to-unsigned
conversion.

If a caller were to pass a negative size, it would be promoted to a large
unsigned value, bypassing the loop bounds check and causing an out-of-bounds
read of raw_data.

While looking at this function, does the subsequent code sleep in atomic
context?

drivers/hid/hid-picolcd_core.c:picolcd_send_and_wait() {
    ...
    spin_lock_irqsave(&data->lock, flags);
    ...
    hid_hw_request(data->hdev, report, HID_REQ_SET_REPORT);
    ...
}

If the HID device is instantiated via the user-space HID subsystem (uhid),
hdev->ll_driver->request is not implemented.

This causes hid_hw_request() to fall back to __hid_request(), which
unconditionally calls hid_alloc_report_buf() with GFP_KERNEL. Allocating
memory with GFP_KERNEL while holding a spinlock violates atomic context rules.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260517120639.38003-1-g.osokin@auroraos.dev?part=1