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

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

Pre-existing issues:
- [High] Concurrent access to sysfs attributes during device unbind leads to NULL pointer dereference or Use-After-Free.
--

commit e5588eae75b51cb3ffbe74aca6501e040a49e90c
Author: Pengpeng Hou [off-list ref]
Date:   Mon Sep 7 18:49:59 2026 +0000

    Input: aiptek - validate raw macro indices before updating state
    
    aiptek_irq() derives macro key indices directly from tablet reports and
    then uses them to index macroKeyEvents[]. Report types 4 and 5 also save
    the derived value in aiptek->lastMacro and later use that state to
    release the previous key.
    
    Validate the raw macro index once before it enters that state machine, so
    lastMacro only ever stores an in-range macro key. Keep direct bounds
    checks for report type 6, which reads the macro number from the packet
    body and uses it immediately.
    
    Link: https://patch.msgid.link/20260329001711.88076-1-pengpeng@iscas.ac.cn

[ ... ]

[Severity: High]
This is a pre-existing issue, but can concurrent access to sysfs attributes
during device unbind lead to a NULL pointer dereference or use-after-free?

Looking at aiptek_disconnect(), the driver data is cleared and the aiptek
structure is freed:

drivers/input/tablet/aiptek.c:aiptek_disconnect() {
    ...
	/* Disassociate driver's struct with usb interface
	 */
	usb_set_intfdata(intf, NULL);
	if (aiptek != NULL) {
		/* Free & unhook everything from the system.
		 */
		usb_kill_urb(aiptek->urb);
		...
		kfree(aiptek);
	}
}

Since the USB driver core removes sysfs files after the disconnect callback
returns, world-readable sysfs handlers like show_tabletToolMode() remain
accessible and can race with the teardown:

drivers/input/tablet/aiptek.c:show_tabletToolMode() {
	struct aiptek *aiptek = dev_get_drvdata(dev);

	return sysfs_emit(buf, "%s\n", map_val_to_str(tool_mode_map,
						      aiptek->curSetting.toolMode));
}

If a sysfs reader calls dev_get_drvdata() after usb_set_intfdata(intf, NULL)
has been executed, it will fetch a NULL pointer and dereference it without
checks.

Alternatively, if the reader fetches the pointer just before it is cleared
but accesses it after kfree(aiptek) finishes, couldn't this trigger a
use-after-free?

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