All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Pawel Zalewski (The Capable Hub)" <pzalewski@thegoodpenguin.co.uk>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH v3 7/8] HID: hid-core: sanitize user input in 'new_id_store'
Date: Mon, 27 Jul 2026 15:08:56 +0000	[thread overview]
Message-ID: <20260727150856.CEAAA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260727-mod-devicetable-hid_device_id-v3-7-980896ca283e@thegoodpenguin.co.uk>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] UAPI/ABI regression in sysfs `new_id` interface due to strict `driver_data` validation.
--

--- Patch [7]: [PATCH v3 7/8] HID: hid-core: sanitize user input in 'new_id_store' ---
commit af3e08832a7fc0ca5b1869fbb2a41b16e167f98f
Author: Pawel Zalewski (The Capable Hub) <pzalewski@thegoodpenguin.co.uk>

HID: hid-core: sanitize user input in 'new_id_store'

This commit restricts the driver_data field in the new_id sysfs interface
to only accept values that match an existing entry in the driver's id_table.
It aims to prevent overriding predefined values within the driver module
with arbitrary entries from the command line.

> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c

[ ... ]

> @@ -2657,6 +2659,22 @@ static ssize_t new_id_store(struct device_driver *drv, const char *buf,
>  	if (ret < 3)
>  		return -EINVAL;
>  
> +	/* Only accept driver_data values that match an
> +	 * existing id_table entry
> +	 */
> +	if (ids) {
> +		ret = -EINVAL;
> +		while (ids->bus) {
> +			if (driver_data == ids->driver_data) {
> +				ret = 0;
> +				break;
> +			}
> +			ids++;
> +		}
> +		if (ret)	/* No match */
> +			return ret;

[Severity: Critical]
Does this loop break the existing userspace ABI for drivers that do not have
an explicit driver_data == 0 entry?

The sysfs new_id interface historically allows users to bind devices dynamically
by writing 3 arguments (bus, vendor, product), which defaults driver_data to 0.
Because this loop terminates when ids->bus == 0, it skips the sentinel entry. 
If a driver's id_table lacks an explicit entry with driver_data == 0, writing
a 3-argument string will now be rejected with -EINVAL.

Can this be adjusted so it doesn't break existing scripts or udev rules that
rely on the default driver_data behavior, or prevent users from testing custom
combinations of quirks?

> +	}
> +
>  	dynid = kzalloc_obj(*dynid);
>  	if (!dynid)
>  		return -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727-mod-devicetable-hid_device_id-v3-0-980896ca283e@thegoodpenguin.co.uk?part=7

  reply	other threads:[~2026-07-27 15:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27 14:55 [PATCH v3 0/8] HID: storing pointers in 'hid_device_id::driver_data' Pawel Zalewski (The Capable Hub)
2026-07-27 14:55 ` [PATCH v3 1/8] HID: hid-input: use named initializer for 'hid_battery_quirks[]' Pawel Zalewski (The Capable Hub)
2026-07-27 14:55 ` [PATCH v3 2/8] HID: hid-quirks: use named initializer in 'hid_quirks[]' Pawel Zalewski (The Capable Hub)
2026-07-27 14:55 ` [PATCH v3 3/8] HID: hid-asus: use named initializer for 'asus_devices[]' Pawel Zalewski (The Capable Hub)
2026-07-27 14:55 ` [PATCH v3 4/8] HID: i2c-hid-dmi-quirks: use named initializer for 'i2c_hid_elan_flipped_quirks[]' Pawel Zalewski (The Capable Hub)
2026-07-27 14:55 ` [PATCH v3 5/8] HID: hid-tmff: clean up usage of 'driver_data' Pawel Zalewski (The Capable Hub)
2026-07-27 15:08   ` sashiko-bot
2026-07-27 14:55 ` [PATCH v3 6/8] HID: wacom: cleanup " Pawel Zalewski (The Capable Hub)
2026-07-27 15:11   ` sashiko-bot
2026-07-27 14:55 ` [PATCH v3 7/8] HID: hid-core: sanitize user input in 'new_id_store' Pawel Zalewski (The Capable Hub)
2026-07-27 15:08   ` sashiko-bot [this message]
2026-07-27 14:55 ` [PATCH v3 8/8] HID: wacom: do not use 'driver_data' Pawel Zalewski (The Capable Hub)
2026-07-27 15:18   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260727150856.CEAAA1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=pzalewski@thegoodpenguin.co.uk \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.