[PATCH] HID: pidff: fix OOB write when hid->inputs is empty

[PATCH] HID: pidff: fix OOB write when hid->inputs is empty

[Baul Lee]

hid_pidff_init_with_quirks() derives its input_dev from

	list_entry(hid->inputs.next, struct hid_input, list)

without first checking that hid->inputs is non-empty.  The list member
of struct hid_input is at offset 0, so on an empty list list_entry()
yields &hid->inputs itself and the following hidinput->input load reads
an unrelated member of struct hid_device.  dev is then a type-confused
pointer, and force-feedback init writes through it: each
set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of
the object dev actually aliases, and input_ff_create() adds further
writes of a heap pointer and two function pointers.

Until hid-universal-pidff the only caller was hid_pidff_init() from
usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at
least one hid_input.  universal_pidff_probe() starts the device with
HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls
hid_pidff_init_with_quirks() directly whenever the descriptor carries a
PID usage page, bypassing that gate.  A report descriptor whose only
application collection is on HID_UP_PID leaves hid->inputs empty while
hid_connect() still succeeds through the hidraw claim, so probe reaches
the unguarded list_entry().

The write happens in the USB probe path, on the hotplug workqueue, so
plugging in a malicious device is enough to trigger it; no attacker
software and no logged-in user are required.  KASAN reports an 8-byte
out-of-bounds write in hid_pidff_init_with_quirks() reached from
universal_pidff_probe().

Check for an empty list before deriving dev and return -ENODEV, as the
other HID force-feedback drivers already do.  universal_pidff_probe()
propagates the error and unwinds.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

Fixes: f06bf8d94fff ("HID: Add hid-universal-pidff driver and supported device ids")
Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
Reported-by: Baul Lee <baul.lee@xbow.com>
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
---
 drivers/hid/usbhid/hid-pidff.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index 5f4395f7c645..22951b7ecd17 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -1539,13 +1539,20 @@ static int pidff_check_autocenter(struct pidff_device *pidff,
 int hid_pidff_init_with_quirks(struct hid_device *hid, u32 initial_quirks)
 {
 	struct pidff_device *pidff;
-	struct hid_input *hidinput =
-		list_entry(hid->inputs.next, struct hid_input, list);
-	struct input_dev *dev = hidinput->input;
+	struct hid_input *hidinput;
+	struct input_dev *dev;
 	struct ff_device *ff;
 	int max_effects;
 	int error;
 
+	if (list_empty(&hid->inputs)) {
+		hid_err(hid, "no inputs found\n");
+		return -ENODEV;
+	}
+
+	hidinput = list_first_entry(&hid->inputs, struct hid_input, list);
+	dev = hidinput->input;
+
 	hid_dbg(hid, "starting pid init\n");
 
 	if (list_empty(&hid->report_enum[HID_OUTPUT_REPORT].report_list)) {
-- 
2.50.1 (Apple Git-155)

Re: [PATCH] HID: pidff: fix OOB write when hid->inputs is empty

[sashiko-bot]

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

Pre-existing issues:
- [High] The probe function `universal_pidff_probe()` fails to call `hid_hw_stop()` when `hid_pidff_init_with_quirks()` returns an error, leading to leaked HID resources and an exploitable Use-After-Free.
- [High] Race condition in `hid_pidff_init_with_quirks` leading to a NULL pointer dereference when a malicious userspace process calls the `EVIOCSFF` ioctl between `input_ff_create()` and callback assignment.
--

--- Patch [1]: [PATCH] HID: pidff: fix OOB write when hid->inputs is empty ---
commit 3acaf40e184c8c11b91d10a3096b1beb8e9b142b
Author: Baul Lee <baul.lee@xbow.com>

HID: pidff: fix OOB write when hid->inputs is empty

This commit fixes an out-of-bounds write in hid_pidff_init_with_quirks()
by ensuring that the hid->inputs list is not empty before accessing it.
If the list is empty, the function now returns -ENODEV.

> Check for an empty list before deriving dev and return -ENODEV, as the
> other HID force-feedback drivers already do.  universal_pidff_probe()
> propagates the error and unwinds.

[Severity: High]
This isn't a bug introduced by this patch, but does universal_pidff_probe()
actually fully unwind here?

Looking at universal_pidff_probe() in drivers/hid/hid-universal-pidff.c:

	error = init_function(hdev, id->driver_data);
	if (error) {
		hid_warn(hdev, "Error initialising force feedback\n");
		goto err;
	}
...
err:
	return error;

This error path propagates the initialization error but misses the necessary
hid_hw_stop() call to unwind hid_hw_start(). If universal_pidff_probe()
fails during force feedback initialization, it returns an error without
unwinding hid_hw_start().

This leaves the hidraw and hidinput structures registered but pointing to a
soon-to-be-driverless hid_device. When the physical device is unplugged,
the core skips calling hid_hw_stop() because hdev->driver is NULL.

Could this lead to an exploitable use-after-free condition if a local user
plugs in an untrusted USB device to trigger this -ENODEV return, and then
accesses the lingering /dev/hidrawX node?


> diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
> index 5f4395f7c6458..22951b7ecd174 100644
> --- a/drivers/hid/usbhid/hid-pidff.c
> +++ b/drivers/hid/usbhid/hid-pidff.c
> @@ -1539,13 +1539,20 @@ static int pidff_check_autocenter(struct pidff_device *pidff,
>  int hid_pidff_init_with_quirks(struct hid_device *hid, u32 initial_quirks)
>  {
>  	struct pidff_device *pidff;
> -	struct hid_input *hidinput =
> -		list_entry(hid->inputs.next, struct hid_input, list);
> -	struct input_dev *dev = hidinput->input;
> +	struct hid_input *hidinput;
> +	struct input_dev *dev;
>  	struct ff_device *ff;
>  	int max_effects;
>  	int error;
>  
> +	if (list_empty(&hid->inputs)) {
> +		hid_err(hid, "no inputs found\n");
> +		return -ENODEV;
> +	}
> +
> +	hidinput = list_first_entry(&hid->inputs, struct hid_input, list);
> +	dev = hidinput->input;
> +

[Severity: High]
This isn't a bug introduced by this patch, but is there a race condition
further down in this function during force feedback initialization?

The input device is already fully registered and visible to userspace (via
hidinput_connect()) before hid_pidff_init_with_quirks() is called. When
input_ff_create() is invoked later in this function, it sets the EV_FF bit
on the device and assigns dev->ff.

Immediately after it returns, but before ff->upload and other callbacks are
initialized, a userspace process can open the input node and issue an
EVIOCSFF ioctl:

	error = input_ff_create(dev, max_effects);
	if (error)
		goto fail;

	ff = dev->ff;
	ff->private = pidff;
	ff->upload = pidff_upload_effect;

Could a local unprivileged user trigger a null pointer dereference by
rapidly issuing ioctls on the newly created /dev/input/eventX node, causing
input_ff_upload() to invoke a null ff->upload function pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260726062503.43717-1-baul.lee@xbow.com?part=1