Re: [PATCH 6.6.y] Input: aiptek - validate raw macro indices before updating state

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Unbounded user input in sysfs 'delay' attribute allows arbitrary uninterruptible sleep, hanging USB unbind and device hotplug.
--

commit ba9154b0332977963ad5bed995346ca93b2e47dc
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>

Input: aiptek - validate raw macro indices before updating state

This commit adds bounds checking for raw macro key indices derived from
tablet reports before updating the state in the driver. It ensures the
index does not exceed the macroKeyEvents array bounds to prevent out of
bounds access.

Link: https://patch.msgid.link/20260329001711.88076-1-pengpeng@iscas.ac.cn

> diff --git a/drivers/input/tablet/aiptek.c b/drivers/input/tablet/aiptek.c
> index baabc51547b83..6210cd99d6291 100644
> --- a/drivers/input/tablet/aiptek.c
> +++ b/drivers/input/tablet/aiptek.c

[ ... ]

[Severity: High]
This is a pre-existing issue, and was not introduced by the patch under
review, but while reviewing this file I noticed unbounded user input in the
sysfs delay attribute allows an arbitrary uninterruptible sleep.

In drivers/input/tablet/aiptek.c:store_tabletProgrammableDelay():

    err = kstrtoint(buf, 10, &d);
    if (err)
        return err;

    aiptek->newSetting.programmableDelay = d;

User input is parsed into an integer and stored without bounds checking.
When the execute attribute is subsequently written, this value is used
in aiptek_query():

    msleep(aiptek->curSetting.programmableDelay);

Can this cause a task to block indefinitely in TASK_UNINTERRUPTIBLE?

If a user writes a huge positive or negative integer to the delay sysfs
attribute, the unbounded value is passed to msleep(). While holding a sysfs
active reference, this prevents the sysfs node from being removed.

If this is triggered and the USB device is subsequently disconnected, does
this force the kernel's USB hub event thread to hang indefinitely in
kernfs_drain()? This would deadlock the USB hub and prevent further device
enumeration or disconnection.

Should this sysfs input be clamped to a safe maximum value before being
stored in programmableDelay?

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