* [PATCH 6.19 145/220] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153934.013228280@linuxfoundation.org>
6.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 6.19 144/220] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153934.013228280@linuxfoundation.org>
6.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
callbacks missing them") attempted to fix up the HID drivers that had
missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
Fix potential NULL dereference at raw event handle"), but the alps
driver was missed.
Fix this up by properly checking in the hid-alps driver that it had been
claimed correctly before attempting to process the raw event.
Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Masaki Ota <masaki.ota@jp.alps.com>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* Re: [PATCH v2] iio: orientation: hid-sensor-rotation: use ext_scan_type
From: srinivas pandruvada @ 2026-04-20 15:45 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Lixu Zhang
Cc: Jiri Kosina, Nuno Sá, Andy Shevchenko, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260412152643.68c8f065@jic23-huawei>
+Lixu
On Sun, 2026-04-12 at 15:26 +0100, Jonathan Cameron wrote:
> On Sun, 01 Mar 2026 17:46:48 -0600
> David Lechner <dlechner@baylibre.com> wrote:
>
> > Make use of ext_scan_type to handle the dynamic realbits size of
> > the
> > quaternion data. This lets us implement it using static data rather
> > than
> > having to duplicate the channel info for each driver instance.
> >
> > Signed-off-by: David Lechner <dlechner@baylibre.com>
> > ---
> I'm going to apply this now, but would welcome any additional
> feedback
> from Srinivas or others.
>
> Note, given this is next cycle material now I'll only push the tree
> out
> as testing until I can rebase on rc1.
>
In real world I think report size is always 16 copying from spec.
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Thanks,
Srinivas
> Thanks,
>
> Jonathan
>
> > This is something I noticed we could do while looking at an
> > unrelated
> > bug. I've tested this using the same script from [1] and confirmed
> > that
> > that the scan type didn't change. Before and after are both:
> >
> > $ cat in_rot_quaternion_type
> > le:s16/32X4>>0
> >
> > [1]:
> > https://lore.kernel.org/linux-iio/20260301-iio-fix-timestamp-alignment-v1-1-1a54980bfb90@baylibre.com/
> > ---
> > Changes in v2:
> > - Dropped DEV_ROT_SCAN_TYPE_8BIT.
> > - Tested using /dev/uhid.
> > - Link to v1:
> > https://lore.kernel.org/r/20260214-iio-hid-sensor-rotation-cleanup-v1-1-3aec9a533c0f@baylibre.com
> > ---
> > drivers/iio/orientation/hid-sensor-rotation.c | 71
> > ++++++++++++++++-----------
> > 1 file changed, 43 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/iio/orientation/hid-sensor-rotation.c
> > b/drivers/iio/orientation/hid-sensor-rotation.c
> > index e759f91a710a..3cfd0b323514 100644
> > --- a/drivers/iio/orientation/hid-sensor-rotation.c
> > +++ b/drivers/iio/orientation/hid-sensor-rotation.c
> > @@ -34,6 +34,27 @@ static const u32
> > rotation_sensitivity_addresses[] = {
> > HID_USAGE_SENSOR_ORIENT_QUATERNION,
> > };
> >
> > +enum {
> > + DEV_ROT_SCAN_TYPE_16BIT,
> > + DEV_ROT_SCAN_TYPE_32BIT,
> > +};
> > +
> > +static const struct iio_scan_type dev_rot_scan_types[] = {
> > + [DEV_ROT_SCAN_TYPE_16BIT] = {
> > + .sign = 's',
> > + .realbits = 16,
> > + /* Storage bits has to stay 32 to not break
> > userspace. */
> > + .storagebits = 32,
> > + .repeat = 4,
> > + },
> > + [DEV_ROT_SCAN_TYPE_32BIT] = {
> > + .sign = 's',
> > + .realbits = 32,
> > + .storagebits = 32,
> > + .repeat = 4,
> > + },
> > +};
> > +
> > /* Channel definitions */
> > static const struct iio_chan_spec dev_rot_channels[] = {
> > {
> > @@ -45,23 +66,14 @@ static const struct iio_chan_spec
> > dev_rot_channels[] = {
> > BIT(IIO_CHAN_INFO_OFFSET)
> > |
> > BIT(IIO_CHAN_INFO_SCALE) |
> > BIT(IIO_CHAN_INFO_HYSTERES
> > IS),
> > - .scan_index = 0
> > + .scan_index = 0,
> > + .has_ext_scan_type = 1,
> > + .ext_scan_type = dev_rot_scan_types,
> > + .num_ext_scan_type =
> > ARRAY_SIZE(dev_rot_scan_types),
> > },
> > IIO_CHAN_SOFT_TIMESTAMP(1)
> > };
> >
> > -/* Adjust channel real bits based on report descriptor */
> > -static void dev_rot_adjust_channel_bit_mask(struct iio_chan_spec
> > *chan,
> > - int size)
> > -{
> > - chan->scan_type.sign = 's';
> > - /* Real storage bits will change based on the report desc.
> > */
> > - chan->scan_type.realbits = size * 8;
> > - /* Maximum size of a sample to capture is u32 */
> > - chan->scan_type.storagebits = sizeof(u32) * 8;
> > - chan->scan_type.repeat = 4;
> > -}
> > -
> > /* Channel read_raw handler */
> > static int dev_rot_read_raw(struct iio_dev *indio_dev,
> > struct iio_chan_spec const *chan,
> > @@ -136,9 +148,25 @@ static int dev_rot_write_raw(struct iio_dev
> > *indio_dev,
> > return ret;
> > }
> >
> > +static int dev_rot_get_current_scan_type(const struct iio_dev
> > *indio_dev,
> > + const struct
> > iio_chan_spec *chan)
> > +{
> > + struct dev_rot_state *rot_state = iio_priv(indio_dev);
> > +
> > + switch (rot_state->quaternion.size / 4) {
> > + case sizeof(s16):
> > + return DEV_ROT_SCAN_TYPE_16BIT;
> > + case sizeof(s32):
> > + return DEV_ROT_SCAN_TYPE_32BIT;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > static const struct iio_info dev_rot_info = {
> > .read_raw_multi = &dev_rot_read_raw,
> > .write_raw = &dev_rot_write_raw,
> > + .get_current_scan_type = &dev_rot_get_current_scan_type,
> > };
> >
> > /* Callback handler to send event after all samples are received
> > and captured */
> > @@ -196,7 +224,6 @@ static int dev_rot_capture_sample(struct
> > hid_sensor_hub_device *hsdev,
> > /* Parse report which is specific to an usage id*/
> > static int dev_rot_parse_report(struct platform_device *pdev,
> > struct hid_sensor_hub_device
> > *hsdev,
> > - struct iio_chan_spec *channels,
> > unsigned usage_id,
> > struct dev_rot_state *st)
> > {
> > @@ -210,9 +237,6 @@ static int dev_rot_parse_report(struct
> > platform_device *pdev,
> > if (ret)
> > return ret;
> >
> > - dev_rot_adjust_channel_bit_mask(&channels[0],
> > - st->quaternion.size / 4);
> > -
> > dev_dbg(&pdev->dev, "dev_rot %x:%x\n", st-
> > >quaternion.index,
> > st->quaternion.report_id);
> >
> > @@ -271,22 +295,13 @@ static int hid_dev_rot_probe(struct
> > platform_device *pdev)
> > return ret;
> > }
> >
> > - indio_dev->channels = devm_kmemdup(&pdev->dev,
> > dev_rot_channels,
> > -
> > sizeof(dev_rot_channels),
> > - GFP_KERNEL);
> > - if (!indio_dev->channels) {
> > - dev_err(&pdev->dev, "failed to duplicate
> > channels\n");
> > - return -ENOMEM;
> > - }
> > -
> > - ret = dev_rot_parse_report(pdev, hsdev,
> > - (struct iio_chan_spec
> > *)indio_dev->channels,
> > - hsdev->usage, rot_state);
> > + ret = dev_rot_parse_report(pdev, hsdev, hsdev->usage,
> > rot_state);
> > if (ret) {
> > dev_err(&pdev->dev, "failed to setup
> > attributes\n");
> > return ret;
> > }
> >
> > + indio_dev->channels = dev_rot_channels;
> > indio_dev->num_channels = ARRAY_SIZE(dev_rot_channels);
> > indio_dev->info = &dev_rot_info;
> > indio_dev->name = name;
> >
> > ---
> > base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
> > change-id: 20260214-iio-hid-sensor-rotation-cleanup-84e8410926ef
> >
> > Best regards,
^ permalink raw reply
* Re: [PATCH v2] iio: magnetometer: hid-sensor-magn-3d: prefer 'unsigned int'
From: srinivas pandruvada @ 2026-04-20 15:46 UTC (permalink / raw)
To: Joshua Crofts, jikos, jic23
Cc: dlechner, nuno.sa, andy, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260419180523.37396-1-joshua.crofts1@gmail.com>
On Sun, 2026-04-19 at 20:05 +0200, Joshua Crofts wrote:
> Use 'u32' instead of bare 'unsigned' to resolve checkpatch.pl
> warnings
> and correct type use as defined in the hid_sensor_hub_callbacks
> struct.
>
> No functional change.
>
> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> v2:
> - changed 'unsigned int' to 'u32' per struct definition
>
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index c673f9323e..b01dd53eb1 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> @@ -280,7 +280,7 @@ static const struct iio_info magn_3d_info = {
>
> /* Callback handler to send event after all samples are received and
> captured */
> static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> void *priv)
> {
> struct iio_dev *indio_dev = platform_get_drvdata(priv);
> @@ -302,7 +302,7 @@ static int magn_3d_proc_event(struct
> hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int magn_3d_capture_sample(struct hid_sensor_hub_device
> *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
> @@ -350,7 +350,7 @@ static int magn_3d_parse_report(struct
> platform_device *pdev,
> struct hid_sensor_hub_device *hsdev,
> struct iio_chan_spec **channels,
> int *chan_count,
> - unsigned usage_id,
> + u32 usage_id,
> struct magn_3d_state *st)
> {
> int i;
^ permalink raw reply
* [PATCH 7.0 07/76] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153910.810034134@linuxfoundation.org>
7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 7.0 06/76] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153910.810034134@linuxfoundation.org>
7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
callbacks missing them") attempted to fix up the HID drivers that had
missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
Fix potential NULL dereference at raw event handle"), but the alps
driver was missed.
Fix this up by properly checking in the hid-alps driver that it had been
claimed correctly before attempting to process the raw event.
Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Masaki Ota <masaki.ota@jp.alps.com>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-04-20 15:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, hvilleneuve,
mkorpershoek, matthias.bgg, angelogioacchino.delregno, lee,
alexander.sverdlin, marek.vasut, akurz, devicetree, linux-kernel,
linux-input, linux-arm-kernel, linux-mediatek
In-Reply-To: <aeWtDA7snjJmiF9K@google.com>
Hi Dmitry,
On Sun, 19 Apr 2026 21:47:40 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> Hi Hugo,
>
> On Thu, Mar 12, 2026 at 02:00:58PM -0400, Hugo Villeneuve wrote:
> > +
> > +static void charlieplex_keypad_report_key(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + const unsigned short *keycodes = input->keycode;
> > +
> > + if (keypad->current_code > 0) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->current_code);
> > + input_report_key(input, keycodes[keypad->current_code], 0);
>
> This needs input_sync() as otherwise userspace is free to only recognize
> the last MSC_SCAN event.
Ok, now I get it, my code would have been be working only if it was an
if/else.
>
> > + }
> > +
> > + if (keypad->debounce_code) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->debounce_code);
> > + input_report_key(input, keycodes[keypad->debounce_code], 1);
> > + }
> > +
> > + input_sync(input);
> > + keypad->current_code = keypad->debounce_code;
> > +}
> > +
> > +static void charlieplex_keypad_check_switch_change(struct input_dev *input,
> > + int code)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > +
> > + if (code != keypad->debounce_code) {
> > + keypad->debounce_count = 0;
> > + keypad->debounce_code = code;
> > + } else if (keypad->debounce_count < keypad->debounce_threshold) {
>
> This does not work if debouncing is disabled (debounce threshold is 0).
Yes.
>
> > + keypad->debounce_count++;
> > +
> > + if (keypad->debounce_count >= keypad->debounce_threshold &&
> > + keypad->debounce_code != keypad->current_code)
> > + charlieplex_keypad_report_key(input);
> > + }
> > +}
> > +
> > +static void charlieplex_keypad_poll(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + int code;
> > +
> > + code = 0;
> > + for (unsigned int oline = 0; oline < keypad->nlines; oline++) {
> > + DECLARE_BITMAP(values, MATRIX_MAX_ROWS);
> > + int err;
> > +
> > + /* Activate only one line as output at a time. */
> > + gpiod_direction_output(keypad->line_gpios->desc[oline], 1);
> > +
> > + if (keypad->settling_time_us)
> > + fsleep(keypad->settling_time_us);
> > +
> > + /* Read input on all other lines. */
> > + err = gpiod_get_array_value_cansleep(keypad->line_gpios->ndescs,
> > + keypad->line_gpios->desc,
> > + keypad->line_gpios->info, values);
> > + if (err)
> > + return;
>
> We need to deactivate the line on error too.
Yer, good catch.
>
> > +
> > + for (unsigned int iline = 0; iline < keypad->nlines; iline++) {
> > + if (iline == oline)
> > + continue; /* Do not read active output line. */
> > +
> > + /* Check if GPIO is asserted. */
> > + if (test_bit(iline, values)) {
> > + code = MATRIX_SCAN_CODE(oline, iline,
> > + get_count_order(keypad->nlines));
> > + /*
> > + * Exit loop immediately since we cannot detect
> > + * more than one key press at a time.
> > + */
> > + break;
> > + }
> > + }
> > +
> > + gpiod_direction_input(keypad->line_gpios->desc[oline]);
> > +
> > + if (code)
> > + break;
> > + }
> > +
> > + charlieplex_keypad_check_switch_change(input, code);
> > +}
> > +
> > +static int charlieplex_keypad_init_gpio(struct platform_device *pdev,
> > + struct charlieplex_keypad *keypad)
> > +{
> > + char **pin_names;
> > + char label[32];
> > +
> > + snprintf(label, sizeof(label), "%s-pin", pdev->name);
> > +
> > + keypad->line_gpios = devm_gpiod_get_array(&pdev->dev, "line", GPIOD_IN);
> > + if (IS_ERR(keypad->line_gpios))
> > + return PTR_ERR(keypad->line_gpios);
> > +
> > + keypad->nlines = keypad->line_gpios->ndescs;
> > +
> > + if (keypad->nlines > MATRIX_MAX_ROWS)
> > + return -EINVAL;
> > +
> > + pin_names = devm_kasprintf_strarray(&pdev->dev, label, keypad->nlines);
> > + if (IS_ERR(pin_names))
> > + return PTR_ERR(pin_names);
> > +
> > + for (unsigned int i = 0; i < keypad->line_gpios->ndescs; i++)
> > + gpiod_set_consumer_name(keypad->line_gpios->desc[i], pin_names[i]);
> > +
> > + return 0;
> > +}
> > +
> > +static int charlieplex_keypad_probe(struct platform_device *pdev)
> > +{
> > + struct charlieplex_keypad *keypad;
> > + unsigned int debounce_interval_ms;
> > + unsigned int poll_interval_ms;
> > + struct input_dev *input_dev;
> > + int err;
> > +
> > + keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
> > + if (!keypad)
> > + return -ENOMEM;
> > +
> > + input_dev = devm_input_allocate_device(&pdev->dev);
> > + if (!input_dev)
> > + return -ENOMEM;
> > +
> > + keypad->input_dev = input_dev;
> > +
> > + device_property_read_u32(&pdev->dev, "poll-interval", &poll_interval_ms);
> > + device_property_read_u32(&pdev->dev, "debounce-delay-ms", &debounce_interval_ms);
> > + device_property_read_u32(&pdev->dev, "settling-time-us", &keypad->settling_time_us);
>
> Not all of these are required properties. If they are missing the driver
> will operate on garbage values.
Yes.
>
> > +
> > + keypad->current_code = -1;
> > + keypad->debounce_code = -1;
> > + keypad->debounce_threshold = DIV_ROUND_UP(debounce_interval_ms, poll_interval_ms);
>
> This will bomb if poll interval is 0.
Yes.
>
> > +
> > + err = charlieplex_keypad_init_gpio(pdev, keypad);
> > + if (err)
> > + return err;
> > +
> > + input_dev->name = pdev->name;
> > + input_dev->id.bustype = BUS_HOST;
> > +
> > + err = matrix_keypad_build_keymap(NULL, NULL, keypad->nlines,
> > + keypad->nlines, NULL, input_dev);
> > + if (err)
> > + dev_err_probe(&pdev->dev, -ENOMEM, "failed to build keymap\n");
>
> Missing "return".
>
> > +
> > + if (device_property_read_bool(&pdev->dev, "autorepeat"))
> > + __set_bit(EV_REP, input_dev->evbit);
> > +
> > + input_set_capability(input_dev, EV_MSC, MSC_SCAN);
> > +
> > + err = input_setup_polling(input_dev, charlieplex_keypad_poll);
> > + if (err)
> > + dev_err_probe(&pdev->dev, err, "unable to set up polling\n");
>
> Missing "return".
Ok for both.
> I fixed it up and applied, please take a look in my 'next' branch and
> tell me if I messed up.
Thank you for the review and the fixes.
I tested it on the real hardware and all is good.
So I imagine that it can still go into 7.1 since it is a new driver
and not a modification of an existing one?
--
Hugo Villeneuve
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 2ca45e57ea027fffe3350ae5e21ad9cecb0dce74
From: kernel test robot @ 2026-04-20 14:06 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 2ca45e57ea027fffe3350ae5e21ad9cecb0dce74 Input: charlieplex_keypad - add GPIO charlieplex keypad
elapsed time: 723m
configs tested: 150
configs skipped: 13
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260420 gcc-8.5.0
arc randconfig-002-20260420 gcc-14.3.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm randconfig-001-20260420 gcc-8.5.0
arm randconfig-002-20260420 gcc-12.5.0
arm randconfig-003-20260420 clang-23
arm randconfig-004-20260420 clang-23
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260420 clang-23
arm64 randconfig-002-20260420 clang-23
arm64 randconfig-003-20260420 gcc-8.5.0
arm64 randconfig-004-20260420 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260420 gcc-9.5.0
csky randconfig-002-20260420 gcc-10.5.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon defconfig clang-23
hexagon randconfig-001-20260420 clang-20
hexagon randconfig-002-20260420 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260420 clang-20
i386 buildonly-randconfig-002-20260420 gcc-14
i386 buildonly-randconfig-003-20260420 clang-20
i386 buildonly-randconfig-004-20260420 clang-20
i386 buildonly-randconfig-005-20260420 gcc-14
i386 buildonly-randconfig-006-20260420 gcc-14
i386 defconfig clang-20
i386 randconfig-011-20260420 clang-20
i386 randconfig-012-20260420 gcc-14
i386 randconfig-013-20260420 gcc-14
i386 randconfig-014-20260420 clang-20
i386 randconfig-015-20260420 clang-20
i386 randconfig-016-20260420 gcc-14
i386 randconfig-017-20260420 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch randconfig-001-20260420 gcc-15.2.0
loongarch randconfig-002-20260420 clang-18
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 randconfig-001-20260420 gcc-8.5.0
nios2 randconfig-002-20260420 gcc-8.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc alldefconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260420 gcc-11.5.0
parisc randconfig-002-20260420 gcc-8.5.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260420 gcc-8.5.0
powerpc randconfig-002-20260420 clang-16
powerpc64 randconfig-001-20260420 clang-19
powerpc64 randconfig-002-20260420 clang-18
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv randconfig-001-20260420 gcc-14.3.0
riscv randconfig-002-20260420 gcc-9.5.0
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 randconfig-001-20260420 clang-23
s390 randconfig-002-20260420 gcc-11.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260420 gcc-14.3.0
sh randconfig-002-20260420 gcc-11.5.0
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260420 gcc-15.2.0
sparc randconfig-002-20260420 gcc-8.5.0
sparc sparc64_defconfig gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260420 gcc-9.5.0
sparc64 randconfig-002-20260420 clang-23
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260420 clang-23
um randconfig-002-20260420 gcc-14
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260420 gcc-14
x86_64 buildonly-randconfig-002-20260420 clang-20
x86_64 buildonly-randconfig-003-20260420 gcc-14
x86_64 buildonly-randconfig-004-20260420 gcc-14
x86_64 buildonly-randconfig-005-20260420 gcc-14
x86_64 buildonly-randconfig-006-20260420 gcc-14
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260420 clang-20
x86_64 randconfig-002-20260420 clang-20
x86_64 randconfig-003-20260420 gcc-13
x86_64 randconfig-004-20260420 gcc-14
x86_64 randconfig-005-20260420 clang-20
x86_64 randconfig-006-20260420 gcc-14
x86_64 randconfig-011-20260420 gcc-14
x86_64 randconfig-012-20260420 gcc-14
x86_64 randconfig-013-20260420 clang-20
x86_64 randconfig-014-20260420 gcc-14
x86_64 randconfig-015-20260420 clang-20
x86_64 randconfig-016-20260420 clang-20
x86_64 randconfig-071-20260420 gcc-14
x86_64 randconfig-072-20260420 gcc-14
x86_64 randconfig-073-20260420 gcc-14
x86_64 randconfig-074-20260420 gcc-14
x86_64 randconfig-075-20260420 clang-20
x86_64 randconfig-076-20260420 gcc-12
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001-20260420 gcc-11.5.0
xtensa randconfig-002-20260420 gcc-9.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: input: Add PixArt PAJ7620 gesture sensor
From: Krzysztof Kozlowski @ 2026-04-20 13:59 UTC (permalink / raw)
To: Harpreet Saini
Cc: Rob Herring, linux-input, devicetree, linux-kernel,
Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260418062241.104697-2-sainiharpreet29@yahoo.com>
On Sat, Apr 18, 2026 at 02:22:32AM -0400, Harpreet Saini wrote:
> The binding include mandatory power supplies (vdd, vbus, vled)
Drop this part
> and optional GPIO controller properties to describe the hardware's
> ability to repurpose SPI pins opeating in I2C mode.
And just explain what is the purpose of GPIO controller - is this a GPIO
controller?
Plus language typo, run spell check.
>
> Signed-off-by: Harpreet Saini <sainiharpreet29@yahoo.com>
> ---
> .../bindings/input/pixart,paj7620.yaml | 79 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> 2 files changed, 81 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/pixart,paj7620.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/pixart,paj7620.yaml b/Documentation/devicetree/bindings/input/pixart,paj7620.yaml
> new file mode 100644
> index 000000000000..ad051cf641a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/pixart,paj7620.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/pixart,paj7620.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PixArt PAJ7620 Gesture Sensor
> +
> +maintainers:
> + - Harpreet Saini <sainiharpreet29@yahoo.com>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + The PixArt PAJ7620 is a gesture recognition sensor with an integrated
> + infrared LED and CMOS array. It communicates over an I2C interface and
> + provides gesture data via a dedicated interrupt pin.
> +
> +properties:
> + compatible:
> + const: pixart,paj7620
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + vdd-supply:
> + description: Main power supply.
> +
> + vbus-supply:
> + description: I/O and I2C bus power supply.
> +
> + vled-supply:
> + description: Power for the integrated IR LED.
> +
> + linux,keycodes:
> + minItems: 9
> + maxItems: 9
> + description: |
Do not need '|' unless you need to preserve formatting.
> + List of keycodes mapping to the 9 supported gestures.
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - vdd-supply
> + - vbus-supply
> + - vled-supply
> +
Missing allOf: with $ref to input.yaml schema. You use its properties.
Commit description said SPI, so missing ref to spi-peripheral-props.
> +additionalProperties: false
And this should be then unevaluatedProperties: false.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH AUTOSEL 6.18] HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3
From: Sasha Levin @ 2026-04-20 13:22 UTC (permalink / raw)
To: patches, stable
Cc: leo vriska, Jiri Kosina, Sasha Levin, jikos, bentiss, linux-input,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: leo vriska <leo@60228.dev>
[ Upstream commit 532743944324a873bbaf8620fcabcd0e69e30c36 ]
According to a mailing list report [1], this controller's predecessor
has the same issue. However, it uses the xpad driver instead of HID, so
this quirk wouldn't apply.
[1]: https://lore.kernel.org/linux-input/unufo3$det$1@ciao.gmane.io/
Signed-off-by: leo vriska <leo@60228.dev>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-quirks.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d9d354f1b8847..a245928933454 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -22,6 +22,9 @@
#define USB_DEVICE_ID_3M2256 0x0502
#define USB_DEVICE_ID_3M3266 0x0506
+#define USB_VENDOR_ID_8BITDO 0x2dc8
+#define USB_DEVICE_ID_8BITDO_PRO_3 0x6009
+
#define USB_VENDOR_ID_A4TECH 0x09da
#define USB_DEVICE_ID_A4TECH_WCP32PU 0x0006
#define USB_DEVICE_ID_A4TECH_X5_005D 0x000a
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 3217e436c052c..f6be3ffee0232 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -25,6 +25,7 @@
*/
static const struct hid_device_id hid_quirks[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_8BITDO, USB_DEVICE_ID_8BITDO_PRO_3), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD), HID_QUIRK_BADPAD },
{ HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR), HID_QUIRK_BADPAD },
{ HID_USB_DEVICE(USB_VENDOR_ID_ADATA_XPG, USB_VENDOR_ID_ADATA_XPG_WL_GAMING_MOUSE), HID_QUIRK_ALWAYS_POLL },
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.6] HID: playstation: validate num_touch_reports in DualShock 4 reports
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: patches, stable
Cc: Benoît Sevens, Jiri Kosina, Sasha Levin,
roderick.colenbrander, jikos, bentiss, linux-input, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Benoît Sevens <bsevens@google.com>
[ Upstream commit 82a4fc46330910b4c1d9b189561439d468e3ff11 ]
The DualShock 4 HID driver fails to validate the num_touch_reports field
received from the device in both USB and Bluetooth input reports.
A malicious device could set this field to a value larger than the
allocated size of the touch_reports array (3 for USB, 4 for Bluetooth),
leading to an out-of-bounds read in dualshock4_parse_report().
This can result in kernel memory disclosure when processing malicious
HID reports.
Validate num_touch_reports against the array size for the respective
connection types before processing the touch data.
Signed-off-by: Benoît Sevens <bsevens@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information to make my analysis. Let me compile the
complete assessment.
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject line parse**
Record: `[HID: playstation:]` `[validate]` - validates
`num_touch_reports` in DualShock 4 USB and Bluetooth input reports to
prevent out-of-bounds reads from malicious HID devices.
**Step 1.2: Commit message tags**
Record:
- `Signed-off-by: Benoît Sevens <bsevens@google.com>` - author from
Google (security researcher who has found and fixed multiple HID/USB
vulnerabilities)
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` - HID subsystem
maintainer applied it
- **No** `Fixes:`, `Reported-by:`, `Reviewed-by:`, `Tested-by:`,
`Link:`, or `Cc: stable` tags (expected absence of stable tag - that's
why review is needed)
**Step 1.3: Commit body analysis**
Record: The commit explicitly describes a security vulnerability: a
malicious HID device can set `num_touch_reports` in the input report
payload to an arbitrary u8 value (0-255). Since the `touch_reports[]`
arrays are fixed at size 3 (USB) and 4 (Bluetooth), values >3/4 cause
out-of-bounds reads in `dualshock4_parse_report()`, leading to **kernel
memory disclosure**. Root cause: missing bounds check on device-supplied
count.
**Step 1.4: Hidden bug fix detection**
Record: Not hidden - the commit is explicitly a security fix. The
language "validate" + "malicious device" + "kernel memory disclosure" +
"out-of-bounds read" is textbook security fix vocabulary.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: 1 file (`drivers/hid/hid-playstation.c`), 12 lines added, 0
removed. Modifies one function: `dualshock4_parse_report()`.
Classification: single-file surgical fix.
**Step 2.2: Code flow change**
Record:
- Before: Code blindly trusted `usb->num_touch_reports` and
`bt->num_touch_reports` from device, used them as loop bound for
`touch_reports[]` array access at line 2482.
- After: Validates both fields against `ARRAY_SIZE(touch_reports)`
before use; returns `-EINVAL` with `hid_err()` log on bogus values.
**Step 2.3: Bug mechanism**
Record: Category (f) memory safety / bounds check fix. The
`num_touch_reports` is a u8 field in the HID report, attacker-controlled
(up to 255). The later loop `for (i = 0; i < num_touch_reports; i++) {
struct dualshock4_touch_report *touch_report = &touch_reports[i]; ...}`
dereferences each `touch_report` and reads `.contact`, `.x_hi`, `.x_lo`,
`.y_hi`, `.y_lo` fields, then feeds them into `input_report_abs()`. With
`num_touch_reports=255` (u8 max) × 9 bytes per `dualshock4_touch_report`
= up to 2,295 bytes of OOB read beyond the 64-byte USB (or 78-byte BT)
report buffer. Disclosed content can potentially leak to userspace via
the resulting input events.
**Step 2.4: Fix quality**
Record: Obviously correct - `ARRAY_SIZE()` is the canonical sizeof-based
macro, the comparison is unsigned-safe, and the return path properly
propagates the error. Zero regression risk: only an early return when
invalid input is detected; valid devices (which set num_touch_reports ≤
3 or ≤ 4) are completely unaffected. No locking, memory, or API changes.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
Record: The buggy loop `for (i = 0; i < num_touch_reports; i++)` was
introduced in commit `752038248808a` ("HID: playstation: add DualShock4
touchpad support") by Roderick Colenbrander, 2022-10-29. The BT path
(`bt->num_touch_reports = ...`) was added in `2d77474a239294` same day.
`git describe --contains 752038248808a7` returns `v6.2-rc1~115^2~2^2~11`
— so the bug landed in **v6.2**.
**Step 3.2: Fixes: tag**
Record: No Fixes: tag present. However, git blame clearly points to
`752038248808a` (v6.2) and `2d77474a239294` (v6.2) as the introducing
commits. Neither exists in pre-6.2 stable trees (5.15.y, 5.10.y, 4.19.y,
etc.).
**Step 3.3: File history**
Record: File has seen churn (cleanup commits from Cristian Ciocaltea in
2025-06: u8 migration `134a40c9d6d9b`, alignment fixes `56d7f285bfaa38`,
guard/scoped_guard refactoring `a38d070ffe338`), but none that would
significantly affect the specific hunks modified by this patch. The
`num_touch_reports` access pattern and struct layout are unchanged since
v6.2.
**Step 3.4: Author's other commits**
Record:
```
d802d848308b3 HID: roccat: fix use-after-free in roccat_report_event
2f1763f62909c HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq
082dd785e2086 media: uvcvideo: Refactor frame parsing code...
b909df18ce2a9 ALSA: usb-audio: Fix potential out-of-bound accesses for
Extigy and Mbox
ecf2b43018da9 media: uvcvideo: Skip parsing frames of type
UVC_VS_UNDEFINED
```
Record: Benoît Sevens is a Google security researcher. His HID/USB bug
fixes (e.g., wacom OOB) have been AUTOSEL'd into stable 5.10–6.19.
Strong trust indicator.
**Step 3.5: Dependencies**
Record: Standalone patch. Uses only `ARRAY_SIZE()`, `hid_err()`, and
struct fields that have existed since v6.2. No prerequisites.
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Original submission**
Record: `b4 dig -c 82a4fc4633091` found it immediately at `https://lore.
kernel.org/all/20260323124737.3223129-1-bsevens@google.com/`. Only v1
exists — no review iterations.
**Step 4.2: Recipients**
Record: `b4 dig -w` shows To: Roderick Colenbrander (original DS4
author, Sony), Jiri Kosina (HID maintainer, jikos@kernel.org), Benjamin
Tissoires (HID co-maintainer, bentiss@kernel.org), Cc: linux-input,
linux-kernel. Maintainer-appropriate recipient list.
**Step 4.3: Discussion thread**
Record: Thread saved to `/tmp/playstation-thread.mbox`. Only one reply -
from Jiri Kosina:
> "Applied now to hid.git#for-7.0/upstream-fixes, thanks!"
Applied to the "upstream-fixes" branch, i.e., treated as a bug fix for
the current merge window, not "next". No NAK, no concerns raised. No
explicit stable nomination in the thread, but the maintainer considered
it an urgent fix (upstream-fixes branch).
**Step 4.4: Related series**
Record: Not part of a series - single standalone patch.
**Step 4.5: Stable list history**
Record: No prior stable discussion found for this specific bug. Similar
sibling fix (`HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq`
by the same author) was AUTOSEL'd to stable 5.10-6.19 per public archive
— same author, same class of fix, same quality profile.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions modified**
Record: Only `dualshock4_parse_report()`.
**Step 5.2: Callers**
Record: `dualshock4_parse_report` is assigned to `ps_dev->parse_report`
(line 2720) and called via the dongle path at line 2603 and ultimately
from `ps_raw_event` (line 2824-2825) which is the `.raw_event` callback
in `ps_driver` (line 2923). The chain is: HID core `hid_input_report()`
→ driver's `.raw_event` → `ps_raw_event` → `dualshock4_parse_report`.
This is called for **every input report** from any device matching Sony
PS4 controller USB/BT IDs.
**Step 5.3: Callees**
Record: Inside the loop, `input_mt_slot()`,
`input_mt_report_slot_state()`, `input_report_abs()` consume data read
from `touch_reports[i]`. Reading OOB does not crash directly (these are
arithmetic operations on u8 fields) but the leaked data flows as input
coordinates and touchpoint activity to userspace input event consumers.
**Step 5.4: Reachability**
Record: Triggerable by any device that enumerates with USB VID/PID or BT
identification matching `USB_VENDOR_ID_SONY` +
`USB_DEVICE_ID_SONY_PS4_CONTROLLER[_2]` (list at lines 2893-2903).
Attacker scenarios:
- Physical USB plug of a crafted device
- Bluetooth-proximate attacker masquerading as a DualShock 4
No root privileges required - kernel trusts device-reported data.
**Step 5.5: Similar patterns**
Record: Other HID drivers have similar validation patterns added
recently (wacom_intuos_bt_irq length checks, `HID: multitouch: Check to
ensure report responses match the request`). Same author has
systematically audited HID drivers for malicious-device OOB reads. This
fits the established pattern.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Code presence in stable**
Record: Verified with `git cat-file -p v6.2:drivers/hid/hid-
playstation.c` through `v6.15`. All versions from v6.2 onward contain
the identical vulnerable code (`num_touch_reports` usage). `v6.1` does
NOT contain DS4 support in this file. Affected stable trees: **6.6.y,
6.12.y, 6.15.y, 6.16.y, 6.17.y and any active stable ≥ 6.2**. NOT
affected: 6.1.y, 5.15.y, 5.10.y, 4.19.y.
**Step 6.2: Backport difficulty**
Record: Minor context differences — in pre-2025 stable trees (e.g.,
v6.6), the `u32` is spelled `uint32_t` and `u8` is spelled `uint8_t`.
The actual changed lines (`if (usb->num_touch_reports >
ARRAY_SIZE(usb->touch_reports))`) use only struct field names and
`ARRAY_SIZE`, which are identical across all affected stable trees.
Expected to apply cleanly with a tiny fuzz or minor manual adjustment.
In v6.12+, structs already use `u8` so the patch applies 1:1.
**Step 6.3: Related fixes in stable**
Record: No prior fix for this specific issue in stable.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem**
Record: `drivers/hid/` - HID subsystem, specifically the generic `hid-
playstation` driver covering a widely-used gaming controller family.
IMPORTANT criticality (widely used on desktops, laptops, SteamOS/Steam
Deck, and gaming setups). Security-relevant because HID devices can be
hot-plugged by untrusted users.
**Step 7.2: Subsystem activity**
Record: Active subsystem — 69 commits to this file since initial
addition. Regular fixes and feature additions. Maintainer is responsive
(applied patch within weeks).
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected users**
Record: Anyone with `CONFIG_HID_PLAYSTATION=m/y` (common default in
distros) who connects a DualShock 4 — real or attacker-crafted. Applies
across USB and Bluetooth. Config-dependent but the config is widely
enabled.
**Step 8.2: Trigger conditions**
Record: A device that identifies as Sony PS4 controller (USB VID 0x054C
+ PID 0x05C4/0x09CC, or BT equivalent) sends a crafted input report with
`num_touch_reports > 3` (USB) or `> 4` (BT). Unprivileged attacker can
trigger via physical USB access or Bluetooth proximity + pairing. No
local privileges needed.
**Step 8.3: Severity**
Record: **HIGH severity**. Out-of-bounds read of ~2 KB of adjacent
kernel memory per malicious report. Consequences:
- Kernel memory disclosure (KASLR bypass via pointer leakage, leaking
kernel data structures, potentially credentials/secrets if mapped
nearby)
- No direct crash (no memory writes, no deref of wild pointers) but
information leak is a well-recognized security class
- Sets the stage for chained exploitation
**Step 8.4: Risk-benefit**
Record:
- BENEFIT: High - fixes an exploitable kernel information disclosure in
a widely-deployed driver
- RISK: Very low - 12 lines added, pure input validation, no behavior
change for valid devices, no locking/memory model changes, returns
-EINVAL which drops the report (graceful)
- Ratio: Strongly favors backporting.
## PHASE 9: SYNTHESIS
**Step 9.1: Evidence**
FOR:
- Explicit security fix (kernel memory disclosure) from a Google
security researcher
- Trivially correct input validation (compared with compile-time
ARRAY_SIZE)
- Zero regression risk: only drops malformed reports that already would
have led to OOB reads
- Maintainer applied to `for-7.0/upstream-fixes` (treated as fix-track,
not feature)
- Same author's sibling HID fixes (wacom OOB) have been AUTOSEL'd into
stable
- Reachable by unprivileged users via USB/BT
- Affects all stable trees ≥ 6.2
AGAINST: None material. (Lack of Cc: stable / Fixes: tag is expected and
not a negative signal per the instructions.)
UNRESOLVED: None of substance.
**Step 9.2: Stable rules check**
1. Obviously correct/tested: YES — code is trivially correct; maintainer
applied it
2. Real bug affecting users: YES — any malicious/broken HID device
triggers it
3. Important issue: YES — kernel information disclosure, security-
relevant
4. Small and contained: YES — 12 lines, single file, single function
5. No new features/APIs: YES — pure validation
6. Applies to stable: YES — minor context adjustments for uint8_t/u8 in
older trees, otherwise clean
**Step 9.3: Exception category**
Record: Security fix for existing, shipped, widely-deployed driver -
meets the "fixes a real bug" criterion directly; not needed as a special
exception.
**Step 9.4: Decision**
Backport recommended.
## Explanation
The commit fixes a real kernel information disclosure vulnerability in
the `hid-playstation` driver. A malicious USB or Bluetooth device
advertising Sony PS4 controller IDs can provide a `num_touch_reports`
value larger than the fixed `touch_reports[3]` (USB) or
`touch_reports[4]` (BT) arrays in the HID report struct. The subsequent
loop in `dualshock4_parse_report()` reads up to ~2 KB of adjacent kernel
memory and feeds it to userspace input events, leaking kernel data.
The fix is textbook stable material: 12 lines of added input validation,
zero behavioral change for legitimate devices, no locking/memory model
changes, and no new APIs. The author (Benoît Sevens, Google) has a track
record of similar HID fixes (roccat UAF, wacom OOB) where comparable
fixes have been AUTOSEL'd into stable 5.10–6.19. The HID maintainer
(Jiri Kosina) applied the patch to the upstream-fixes branch, signaling
he considers it a fix rather than a feature.
The buggy code landed in v6.2 (commits `752038248808a`,
`2d77474a239294`), so stable trees ≥ 6.2 (6.6.y, 6.12.y, etc.) are all
affected and should receive this fix. The patch should apply cleanly
with only minor context fuzz in pre-`u8` stable branches.
## Verification
- [Phase 1] Parsed tags: only SoB tags, no Reported-by/Fixes/Cc:stable.
Verified by reading commit message.
- [Phase 2] Diff analysis: verified 12 added lines in
`dualshock4_parse_report()` - two parallel `if (usb->num_touch_reports
> ARRAY_SIZE(usb->touch_reports))` / `... bt->... >
ARRAY_SIZE(bt->touch_reports)` checks with `hid_err()` + `return
-EINVAL`.
- [Phase 2] Verified struct layouts: `struct
dualshock4_input_report_usb.touch_reports[3]` (line 482), `struct
dualshock4_input_report_bt.touch_reports[4]` (line 492),
`num_touch_reports` is u8 (lines 481, 491).
- [Phase 2] Verified consumer loop at line 2482: `for (i = 0; i <
num_touch_reports; i++) { struct dualshock4_touch_report *touch_report
= &touch_reports[i]; ... }` confirms OOB read.
- [Phase 3] `git blame -L 2482,2483` confirmed buggy loop introduced by
commit `752038248808a7` (Roderick Colenbrander, 2022-10-29).
- [Phase 3] `git blame -L 2380,2396` confirmed BT path introduced by
`2d77474a239294`.
- [Phase 3] `git describe --contains 752038248808a7` =
`v6.2-rc1~115^2~2^2~11`; `2d77474a239294` = `v6.2-rc1~115^2~2^2~4` —
both are pre-v6.2 rc1, so land in v6.2.
- [Phase 3] Author commit list: `git log --author="bsevens"` shows
roccat UAF, wacom OOB, ALSA Extigy OOB - consistent security fix
pattern.
- [Phase 4] `b4 dig -c 82a4fc4633091` found submission at `https://lore.
kernel.org/all/20260323124737.3223129-1-bsevens@google.com/`.
- [Phase 4] `b4 dig -a`: only v1 - no review iterations.
- [Phase 4] `b4 dig -w`: recipients = Roderick Colenbrander (Sony), Jiri
Kosina, Benjamin Tissoires, linux-input. Appropriate.
- [Phase 4] `b4 dig -m` + read /tmp/playstation-thread.mbox: Jiri Kosina
reply confirms "Applied now to hid.git#for-7.0/upstream-fixes,
thanks!" - treated as fix.
- [Phase 4] Web search confirmed sibling `HID: wacom: fix out-of-bounds
read in wacom_intuos_bt_irq` was AUTOSEL'd to 5.10-6.19 stable.
- [Phase 5] Verified call chain: `.raw_event = ps_raw_event` (line 2923)
→ `ps_raw_event` (2819) → `dev->parse_report` (2825) assigned to
`dualshock4_parse_report` at line 2720.
- [Phase 5] Verified ID table at lines 2893-2903 (Sony PS4 USB + BT
IDs).
- [Phase 6] `git cat-file -p vX:drivers/hid/hid-playstation.c | grep
num_touch_reports` for v6.2-v6.15 each returned 6 matches — consistent
code present across all post-v6.2 trees; v6.1 returned 0 (driver path
absent).
- [Phase 6] Verified v6.6 struct definitions (uint8_t spelling) — patch
would need trivial context refit for pre-2025 stable trees but target
lines are identical.
- UNVERIFIED: Whether the raw HID buffer passed into `raw_event` in
practice is always exactly 64/78 bytes or larger (irrelevant to
decision — even at 64+7 bytes, 255 touch entries still far exceeds the
buffer, so the security impact holds).
**YES**
drivers/hid/hid-playstation.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 3c0db8f93c829..c43caac20b61b 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2377,6 +2377,12 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
struct dualshock4_input_report_usb *usb =
(struct dualshock4_input_report_usb *)data;
+ if (usb->num_touch_reports > ARRAY_SIZE(usb->touch_reports)) {
+ hid_err(hdev, "DualShock4 USB input report has invalid num_touch_reports=%d\n",
+ usb->num_touch_reports);
+ return -EINVAL;
+ }
+
ds4_report = &usb->common;
num_touch_reports = usb->num_touch_reports;
touch_reports = usb->touch_reports;
@@ -2391,6 +2397,12 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
return -EILSEQ;
}
+ if (bt->num_touch_reports > ARRAY_SIZE(bt->touch_reports)) {
+ hid_err(hdev, "DualShock4 BT input report has invalid num_touch_reports=%d\n",
+ bt->num_touch_reports);
+ return -EINVAL;
+ }
+
ds4_report = &bt->common;
num_touch_reports = bt->num_touch_reports;
touch_reports = bt->touch_reports;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: patches, stable
Cc: Even Xu, Jiri Kosina, Sasha Levin, xinpeng.sun, jikos, bentiss,
linux-input, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Even Xu <even.xu@intel.com>
[ Upstream commit 48e91af0cbe942d50ef6257d850accdca1d01378 ]
Add Nova Lake THC QuickSPI device IDs to support list.
Signed-off-by: Even Xu <even.xu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 6 ++++++
drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
index 14cabd5dc6ddb..f0830a56d556b 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
@@ -37,6 +37,10 @@ struct quickspi_driver_data arl = {
.max_packet_size_value = MAX_PACKET_SIZE_VALUE_MTL,
};
+struct quickspi_driver_data nvl = {
+ .max_packet_size_value = MAX_PACKET_SIZE_VALUE_LNL,
+};
+
/* THC QuickSPI ACPI method to get device properties */
/* HIDSPI Method: {6e2ac436-0fcf-41af-a265-b32a220dcfab} */
static guid_t hidspi_guid =
@@ -984,6 +988,8 @@ static const struct pci_device_id quickspi_pci_tbl[] = {
{PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_SPI_PORT2, &ptl), },
{PCI_DEVICE_DATA(INTEL, THC_ARL_DEVICE_ID_SPI_PORT1, &arl), },
{PCI_DEVICE_DATA(INTEL, THC_ARL_DEVICE_ID_SPI_PORT2, &arl), },
+ {PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_SPI_PORT1, &nvl), },
+ {PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_SPI_PORT2, &nvl), },
{}
};
MODULE_DEVICE_TABLE(pci, quickspi_pci_tbl);
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
index c30e1a42eb098..bf5e18f5a5f42 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
@@ -23,6 +23,8 @@
#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_SPI_PORT2 0x4D4B
#define PCI_DEVICE_ID_INTEL_THC_ARL_DEVICE_ID_SPI_PORT1 0x7749
#define PCI_DEVICE_ID_INTEL_THC_ARL_DEVICE_ID_SPI_PORT2 0x774B
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_SPI_PORT1 0xD349
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_SPI_PORT2 0xD34B
/* HIDSPI special ACPI parameters DSM methods */
#define ACPI_QUICKSPI_REVISION_NUM 2
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.15] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
From: Sasha Levin @ 2026-04-20 13:19 UTC (permalink / raw)
To: patches, stable
Cc: Nícolas F. R. A. Prado, Jiri Kosina, Sasha Levin, jikos,
bentiss, linux-input, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Nícolas F. R. A. Prado <nfraprado@collabora.com>
[ Upstream commit d4229fc0cb50c52b385538d072c5fc8827b287a9 ]
The Logitech Bolt receiver once connected to a wireless device will
generate data on interface 2. If this data isn't polled, when the USB
port it is connected to gets suspended (and if that happens within 5
minutes of the last input from the wireless device), it will trigger a
remote wakeup 3 seconds later, which will result in a spurious system
wakeup if the port was suspended as part of system sleep.
Set the ALWAYS_POLL quirk for this device to ensure interface 2 is
always polled and this spurious wakeup never happens.
With this change in place the system can be suspended with the receiver
plugged in and the system can be woken up when an input is sent from the
wireless device.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed. Let me compile the analysis.
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line Parse**
- Subsystem prefix: `HID: quirks:`
- Action verb: "Set" (adds a quirk entry - this is effectively fixing
broken hardware behavior)
- Record: HID subsystem; adding `HID_QUIRK_ALWAYS_POLL` for the Logitech
Bolt Receiver.
**Step 1.2: All Tags**
- `Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>`
(author)
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID subsystem
maintainer)
- No Fixes:, no Cc: stable, no Reported-by:, no Link: (expected — that's
why it needs review)
- Record: Applied by HID maintainer directly; concise author-maintainer
chain.
**Step 1.3: Body Analysis**
- Bug mechanism: Once a wireless device connects to the Bolt receiver,
interface 2 generates data. If not polled and the USB port is
suspended within 5 min of last wireless input, the device triggers a
remote wakeup 3 seconds later, causing a spurious system wakeup when
suspended as part of system sleep.
- Symptom: **System spontaneously wakes from suspend** when Bolt
receiver is attached.
- Author confirms testing: "With this change in place the system can be
suspended with the receiver plugged in and the system can be woken up
when an input is sent from the wireless device."
- Record: Real, observed, user-visible issue (spurious wake-from-
suspend); root cause clearly identified (device emits data on
interface 2 that triggers remote wakeup).
**Step 1.4: Hidden Bug Fix Detection**
- "Set ALWAYS_POLL" — this is a hardware workaround/quirk. Functionally,
it is a **bug fix** for buggy hardware behavior that breaks system
suspend for affected users.
- Record: This is a classic hardware quirk bug fix.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Files: `drivers/hid/hid-quirks.c` only, +1/-0 lines.
- Functions: none — adds a single table entry to `hid_quirks[]`.
- Classification: trivial, single-file, surgical quirk table entry.
**Step 2.2: Code Flow**
- Before: device matched only by default HID logic → `usbhid_open()` and
related code treated it like any normal device (autosuspend-enabled,
sets `needs_remote_wakeup = 1`).
- After: the quirk flag makes `usbhid/hid-core.c` paths at lines 689,
752, 756, 1185, 1234 bypass autosuspend/remote wakeup logic —
`needs_remote_wakeup` stays 0 and interface 2 is always polled.
- Record: exactly the change documented in commit message.
**Step 2.3: Bug Mechanism**
- Category: (h) Hardware workaround / quirk table entry for buggy device
behavior.
- Mechanism: `HID_QUIRK_ALWAYS_POLL` is an established mechanism used by
many Logitech, Lenovo, Microsoft, Chicony mice/dongles for exactly
this kind of problem (preventing spurious wakeups / keeping endpoint
pollable). The Bolt receiver exhibits the same pattern.
**Step 2.4: Fix Quality**
- Obviously correct: trivial one-line addition to an existing quirk
table.
- Minimal and surgical: yes.
- Regression risk: essentially zero — the quirk only affects devices
matching vendor=0x046d, product=0xc548. All other devices are
untouched.
- Risk introduced by the fix itself: slight extra USB traffic for Bolt
receiver users (acknowledged by author). This is well within
acceptable for the quirk behavior that's applied to many devices
already.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- `USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` define added in commit
`526748b925185` ("HID: multitouch: Add quirk for Logitech Bolt
receiver w/ Casa touchpad") — first shipped in **v6.12**.
- Record: buggy hardware behavior exists since device was first
supported; device ID is present in stable 6.12.y and later.
**Step 3.2: Fixes Tag**
- No Fixes: tag (device behavior is a hardware issue, not a regression
from a specific commit). Not applicable.
**Step 3.3: File History**
- `drivers/hid/hid-quirks.c` receives quirk additions routinely (VRS
steering wheel, Cooler Master MM712, Apple keyboards,
Lenovo/Edifier/etc.). This is the normal pattern.
- Record: no prerequisite patches; standalone one-line addition.
**Step 3.4: Author**
- Author is a Collabora Mediatek/Genio/thermal/kernel developer (regular
upstream contributor). Applied by HID maintainer Jiri Kosina directly.
- Record: normal maintainer acceptance path.
**Step 3.5: Dependencies**
- Uses `USB_VENDOR_ID_LOGITECH` (long-existing) and
`USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` (added in v6.12). No other
dependencies.
- Record: applies cleanly to any stable tree ≥ 6.12. Older trees (6.6,
6.1, 5.15, 5.10, 5.4) do not have the device ID define; backport would
need the `hid-ids.h` define too — likely not worth doing given the
device ID was added in 6.12.
## PHASE 4: MAILING LIST
**Step 4.1: Original thread**
- `b4 dig -c d4229fc0cb50c` → https://lore.kernel.org/all/20260407-logi-
bolt-hid-quirk-always-poll-v1-1-4dae0fda344e@collabora.com/
- Single revision (v1). Applied as submitted.
**Step 4.2: Reviewers**
- Thread saved to mbox. Jiri Kosina (HID maintainer, `jikos@kernel.org`)
replied: "In the meantime, I am applying this one. Thanks,"
- Author proposed possible future improvement (a "poll-before-suspend
only" quirk) but Jiri didn't object to the current approach.
- Recipients: Jiri Kosina, Benjamin Tissoires, linux-
input@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@collabora.com.
- Record: patch reviewed and applied by the subsystem maintainer with no
objections; no stable nomination request was made but also no concerns
raised.
**Step 4.3: Bug Report**
- No Link: tag, but commit message and author's reply indicate this is a
directly-observed reproducible issue.
**Step 4.4: Series context**
- `b4 dig -a`: only v1 exists. Standalone single patch.
**Step 4.5: Stable discussion**
- None found in thread.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions modified**
- None. Adds one table entry to `hid_quirks[]` consumed by
`usbhid_exists_squirk()` / `hid_lookup_quirk()`.
**Step 5.2: Callers of quirk**
- `drivers/hid/usbhid/hid-core.c`: lines 689, 752, 756, 1185, 1234 all
check `HID_QUIRK_ALWAYS_POLL` and branch accordingly in `usbhid_open`,
`usbhid_close`, `usbhid_start`, `usbhid_stop` (standard HID USB device
lifecycle).
- Record: well-established, widely-used quirk path.
**Step 5.3: Callees**
- N/A — this is a data table entry.
**Step 5.4: Reachability**
- Reached for any system with the Bolt receiver plugged in during device
enumeration — every affected user.
**Step 5.5: Similar patterns**
- Many similar quirk additions in same file (Apple keyboard
c55092187d9ad, Dell KM5221W 62cc9c3cb3ec1, VRS R295 1141ed52348d3,
Cooler Master MM712 0be4253bf878d, Lenovo PixArt mice, etc.). This is
a recurring, well-accepted pattern.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Code exists in stable?**
- The device ID `USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER = 0xc548` is in
stable 6.12.y and later (added by commit 526748b925185 before v6.12).
- The `hid_quirks[]` table exists in all stable trees.
- Record: backport applicable to 6.12.y, 6.13.y, 6.14.y, 6.15.y (current
active trees that carry the define). Not applicable to older LTS
(6.6.y, 6.1.y, 5.15.y, 5.10.y) unless the device ID define is
backported along.
**Step 6.2: Backport complications**
- Mainline hunk context includes neighboring entries added later (8BitDo
Pro 3, Edifier QR30). Fuzz/minor context adjustment likely sufficient;
any stable tree with the `LOGITECH_BOLT_RECEIVER` define will accept
this addition trivially — the surrounding entries have been stable for
years.
- Record: clean apply with possibly trivial fuzz on older-than-mainline
stable.
**Step 6.3: Related fixes in stable?**
- None found.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem**
- `drivers/hid/` — device drivers (HID, USB input).
- Criticality: IMPORTANT — keyboards, mice, and wireless receivers are
common desktop/laptop hardware. Suspend/resume breakage affects user-
visible laptop power management.
**Step 7.2: Activity**
- Very active file; routine quirk additions merged frequently.
## PHASE 8: IMPACT AND RISK
**Step 8.1: Affected users**
- Owners of Logitech Bolt receivers (a fairly popular wireless receiver
used with Logitech MX-family peripherals and modern wireless
keyboards/mice) who suspend their systems.
**Step 8.2: Trigger**
- Occurs every system suspend within 5 minutes of wireless input
activity. Very easy to trigger on any laptop using this receiver.
**Step 8.3: Severity**
- Failure mode: **spurious wake-from-suspend** → battery drain, system
not actually suspending, potential data/security exposure on machines
users thought were asleep. Severity: **MEDIUM-HIGH** (not a crash, but
a serious user-visible regression of the suspend feature; affects
laptop battery life and sleep reliability).
**Step 8.4: Risk-benefit**
- Benefit: clear, reproducible user-facing fix for laptop suspend/resume
with a common wireless receiver.
- Risk: one-line table entry for a specific (vendor,product) tuple;
cannot affect other devices. Extra URB polling for the one device —
the same trade-off accepted for dozens of similar quirks. Very low
risk.
- Record: benefit >> risk.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
- FOR: one-line surgical quirk; applied by HID maintainer; established
pattern (dozens of similar entries); fixes real user-visible suspend
misbehavior; author tested both suspend and wakeup paths.
- AGAINST: none material. Adds a tiny bit of USB traffic for the one
device (acknowledged).
- Unresolved: backport to pre-6.12 trees would additionally need the
`hid-ids.h` define from commit 526748b925185 — but active stable trees
(6.12.y+) already contain it.
**Step 9.2: Stable Rules Checklist**
1. Obviously correct? **YES** — matches existing pattern, maintainer-
applied.
2. Fixes real bug affecting users? **YES** — spurious wake from suspend.
3. Important issue? **YES** — suspend/resume reliability on common
hardware.
4. Small and contained? **YES** — 1 line, 1 file.
5. No new features/APIs? **YES** — quirk entry only.
6. Applies to stable? **YES** — for trees containing the device ID
define (v6.12+).
**Step 9.3: Exception Category**
- Fits the explicit "QUIRKS and WORKAROUNDS" exception and "NEW DEVICE
IDs / device-specific quirks to existing drivers" exception in stable
rules.
**Step 9.4: Decision**
- This is a textbook stable candidate: a minimal, targeted hardware
quirk that fixes a reproducible suspend issue for a common piece of
hardware, applied by the subsystem maintainer, matching dozens of
prior similar backported quirks.
## Verification
- [Phase 1] Parsed commit message: confirmed no
Fixes/Cc:stable/Link/Reported-by; two Signed-off-bys (author + HID
maintainer Jiri Kosina).
- [Phase 2] Diff inspection: verified the change is exactly `+1` line in
`drivers/hid/hid-quirks.c` adding a `HID_QUIRK_ALWAYS_POLL` entry for
`USB_VENDOR_ID_LOGITECH`/`USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER`.
- [Phase 2] Confirmed quirk semantics via `drivers/hid/usbhid/hid-
core.c` lines 689, 752, 756, 1185, 1234 — flag bypasses
autosuspend/remote-wakeup paths.
- [Phase 2] Verified `HID_QUIRK_ALWAYS_POLL = BIT(10)` in
`include/linux/hid.h:406`.
- [Phase 3] `git log` on `drivers/hid/hid-quirks.c` + `rg
USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` → identified define introduced
in commit `526748b925185`.
- [Phase 3] `git tag --contains 526748b925185` → device ID first shipped
in v6.12.
- [Phase 3] `git log --oneline --grep="ALWAYS_POLL"` → verified many
similar one-line quirk additions historically.
- [Phase 4] `b4 dig -c d4229fc0cb50c` → found original thread at
lore.kernel.org/all/20260407-logi-bolt-hid-quirk-always-
poll-v1-1-4dae0fda344e@collabora.com/.
- [Phase 4] `b4 dig -a` → single v1, applied as-is.
- [Phase 4] `b4 dig -m /tmp/bolt-thread.mbx` → read full thread: Jiri
Kosina (HID maintainer) applied the patch; author confirmed testing;
no NAKs.
- [Phase 5] Confirmed `hid_quirks[]` entries are consumed by the
standard USB HID core paths — impact scope is exactly the one matched
device.
- [Phase 6] Device ID present in mainline and 6.12.y+ stable branches.
- [Phase 7] `drivers/hid/` is IMPORTANT subsystem — affects HID input on
desktops/laptops.
- [Phase 8] Failure mode: spurious system wake from suspend, confirmed
by commit message text.
- UNVERIFIED: I did not check every LTS stable tree file-by-file for
divergent context around the insertion point, but given this is a
sorted alphabetical table and the neighboring Logitech entries
(`LOGITECH_C007`, `LOGITECH_C077`, `LOGITECH_KEYBOARD_G710_PLUS`) have
been present for many years, a clean backport is essentially
guaranteed for 6.12+ trees.
Single-line hardware quirk entry that fixes a real, reproducible
suspend/wakeup bug affecting owners of the Logitech Bolt receiver.
Matches the "quirks and workarounds" stable exception exactly, is
maintainer-applied, carries negligible regression risk, and applies
cleanly to stable trees that carry the device ID (v6.12+).
**YES**
drivers/hid/hid-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 02f7db5c10564..eb811b1fb80f9 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -134,6 +134,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_602E), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6093), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C007), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS), HID_QUIRK_NOGET },
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] HID: roccat: fix use-after-free in roccat_report_event
From: Sasha Levin @ 2026-04-20 13:18 UTC (permalink / raw)
To: patches, stable
Cc: Benoît Sevens, Silvan Jegen, Jiri Kosina, Sasha Levin,
erazor_de, jikos, bentiss, linux-input, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Benoît Sevens <bsevens@google.com>
[ Upstream commit d802d848308b35220f21a8025352f0c0aba15c12 ]
roccat_report_event() iterates over the device->readers list without
holding the readers_lock. This allows a concurrent roccat_release() to
remove and free a reader while it's still being accessed, leading to a
use-after-free.
Protect the readers list traversal with the readers_lock mutex.
Signed-off-by: Benoît Sevens <bsevens@google.com>
Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/hid/hid-roccat.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
index c7f7562e22e56..e413662f75082 100644
--- a/drivers/hid/hid-roccat.c
+++ b/drivers/hid/hid-roccat.c
@@ -257,6 +257,7 @@ int roccat_report_event(int minor, u8 const *data)
if (!new_value)
return -ENOMEM;
+ mutex_lock(&device->readers_lock);
mutex_lock(&device->cbuf_lock);
report = &device->cbuf[device->cbuf_end];
@@ -279,6 +280,7 @@ int roccat_report_event(int minor, u8 const *data)
}
mutex_unlock(&device->cbuf_lock);
+ mutex_unlock(&device->readers_lock);
wake_up_interruptible(&device->wait);
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP
From: Sasha Levin @ 2026-04-20 13:16 UTC (permalink / raw)
To: patches, stable
Cc: Maximilian Pezzullo, Casey Croy, Basavaraj Natikar, Jiri Kosina,
Sasha Levin, basavaraj.natikar, jikos, bentiss, linux-input,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Maximilian Pezzullo <maximilianpezzullo@gmail.com>
[ Upstream commit 743677a8cb30b09f16a7f167f497c2c927891b5a ]
When sensor discovery fails on systems without AMD SFH sensors, the
code already emits a warning via dev_warn() in amd_sfh_hid_client_init().
The subsequent dev_err() in sfh_init_work() for the same -EOPNOTSUPP
return value is redundant and causes unnecessary alarm.
Suppress the dev_err() for -EOPNOTSUPP to avoid confusing users who
have no AMD SFH sensors.
Fixes: 2105e8e00da4 ("HID: amd_sfh: Improve boot time when SFH is available")
Reported-by: Casey Croy <ccroy@bugzilla.kernel.org>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221099
Signed-off-by: Maximilian Pezzullo <maximilianpezzullo@gmail.com>
Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
index 1d9f955573aa4..4b81cebdc3359 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
@@ -413,7 +413,8 @@ static void sfh_init_work(struct work_struct *work)
rc = amd_sfh_hid_client_init(mp2);
if (rc) {
amd_sfh_clear_intr(mp2);
- dev_err(&pdev->dev, "amd_sfh_hid_client_init failed err %d\n", rc);
+ if (rc != -EOPNOTSUPP)
+ dev_err(&pdev->dev, "amd_sfh_hid_client_init failed err %d\n", rc);
return;
}
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Günther Noack, Lee Jones, Jiri Kosina, Sasha Levin, jikos,
bentiss, linux-input, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Günther Noack <gnoack@google.com>
[ Upstream commit e606d8329be1e19b7eb3e0c6c72a73cbbb25ae3d ]
Without this bounds check, this might otherwise overwrite index -1.
Triggering this condition requires action both from the USB device and from
userspace, which reduces the scenarios in which it can be exploited.
Cc: Lee Jones <lee@kernel.org>
Signed-off-by: Günther Noack <gnoack@google.com>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis
### PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Parse subject line**
Record: Subsystem `HID: logitech-hidpp:`, action verb `Check` (adding a
missing check). Summary: add missing bounds-check when deleting force-
feedback effects.
**Step 1.2: Parse commit message tags**
Record:
- `Cc: Lee Jones <lee@kernel.org>` (HID area reviewer, not stable)
- `Signed-off-by: Günther Noack <gnoack@google.com>` (author - Google
security engineer)
- `Reviewed-by: Lee Jones <lee@kernel.org>`
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID maintainer)
- **NOT** present: `Cc: stable@vger.kernel.org`, `Fixes:`, `Reported-
by:`, `Link:`
- No syzbot, no user bug report, no sanitizer report
**Step 1.3: Analyze commit body**
Record: Author describes a missing bounds check that "might otherwise
overwrite index -1". Explicitly notes reduced exploitability:
"Triggering this condition requires action both from the USB device and
from userspace, which reduces the scenarios in which it can be
exploited." This is a security-hardening fix with an author-acknowledged
limited attack surface.
**Step 1.4: Hidden bug fix?**
Record: Not hidden at all - clearly a bug fix (missing bounds check
preventing OOB write). The "Check bounds" phrasing is classic stable-
style bug fix language.
### PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: 1 file modified: `drivers/hid/hid-logitech-hidpp.c`. 9 lines
added, 6 removed. Single function modified: `hidpp_ff_work_handler()`,
single switch case: `HIDPP_FF_DESTROY_EFFECT`. Classification: single-
file surgical fix.
**Step 2.2: Code flow change**
Record:
- BEFORE: In `HIDPP_FF_DESTROY_EFFECT`, unconditionally writes
`data->effect_ids[wd->params[0]-1] = -1` when `effect_id >= 0`. No
bounds check on `wd->params[0]`.
- AFTER: First reads `slot = wd->params[0]`, then wraps the writes in
`if (slot > 0 && slot <= data->num_effects)`.
- This is an error-path / invalid-state handling fix, but on a normal
runtime path.
**Step 2.3: Bug mechanism**
Record: Category (f) Memory safety - bounds check added. Specific
mechanism: `wd->params[0]` is set by `hidpp_ff_find_effect()` (line
2478), which returns 0 when the requested `effect_id` is not present in
`data->effect_ids[]`. For `HIDPP_FF_EFFECTID_AUTOCENTER`, it's set to
`data->slot_autocenter` (initially 0 before autocenter is uploaded).
When `params[0] == 0`, the expression `params[0] - 1` promotes through
int arithmetic to `-1`, causing `data->effect_ids[-1] = -1` - an out-of-
bounds write of a fixed value `-1` at index `-1` of a
`kzalloc`-allocated `int*` array. The analogous
`HIDPP_FF_DOWNLOAD_EFFECT` case (lines 2493-2502) already contains the
exact same defensive check `if (slot > 0 && slot <= data->num_effects)`
- this fix restores symmetry.
**Step 2.4: Fix quality**
Record: Obviously correct - mirrors existing defensive check from the
same function's DOWNLOAD case. Minimal/surgical. Zero regression risk:
the added condition only suppresses an invalid index write; it doesn't
restrict any legitimate behavior. No red flags.
### PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: git blame**
Record: The buggy `HIDPP_FF_DESTROY_EFFECT` handler was introduced by
commit `ff21a635dd1a9c` (Edwin Velds, 2016-01-11) "HID: logitech-hidpp:
Force feedback support for the Logitech G920". `git describe --contains`
places it at `v4.6-rc1~107^2^4~1` - first appeared in v4.6. The code has
been stable for ~10 years and is present in every supported stable tree.
**Step 3.2: Follow Fixes: tag**
Record: No `Fixes:` tag in the commit, but git blame identifies the
introducing commit as `ff21a635dd1a9c` (v4.6). That original commit is
in all stable trees that fork from ≥v4.6, which is every currently-
supported stable tree (5.4, 5.10, 5.15, 6.1, 6.6, 6.12, 6.19).
**Step 3.3: Related recent changes**
Record: Recent related work:
- `f7a4c78bfeb32` (Feb 2026) - Lee Jones, "Prevent use-after-free on
force feedback initialisation failure" - UAF fix in same FF path, no
`Cc: stable`.
- `1547d41f9f19d` (Jan 2026) - Günther Noack, "Check maxfield in
hidpp_get_report_length()" - hardening fix, **has** `Cc: stable`.
- This commit is standalone and self-contained; not part of a series (b4
dig -a shows only v1).
**Step 3.4: Author's other commits**
Record: Günther Noack (Google) has been actively hardening HID drivers
against malicious/fake USB devices: `HID: asus: avoid memory leak`,
`HID: magicmouse: Do not crash on missing msc->input` (+Cc stable),
`HID: prodikeys: Check presence of pm->input_ep82` (+Cc stable), `HID:
logitech-hidpp: Check maxfield in hidpp_get_report_length()` (+Cc
stable). Author is credible, security-focused, and knows stable
conventions.
**Step 3.5: Dependencies**
Record: No dependencies. Standalone, self-contained fix.
### PHASE 4: MAILING LIST / EXTERNAL RESEARCH
**Step 4.1: b4 dig original submission**
Record: `b4 dig -c e606d8329be1e` returned a single-message thread at `h
ttps://lore.kernel.org/all/20260331074052.194064-1-gnoack@google.com/`.
`b4 dig -a` confirms only v1 was posted - no revision history.
**Step 4.2: Recipients**
Record: `b4 dig -w` shows patch was sent to Filipe Laíns, Bastien
Nocera, Jiri Kosina (HID maintainer), Benjamin Tissoires (HID co-
maintainer), Lee Jones, linux-input@vger.kernel.org, linux-
kernel@vger.kernel.org. Appropriate audience.
**Step 4.3: Bug report**
Record: No bug report referenced; no syzbot/KASAN/KMSAN tag. Appears to
be a code-audit / hardening finding by the author.
**Step 4.4: Thread discussion**
Record: Thread saved to `/tmp/hidpp_thread.mbox`. Contents:
- Lee Jones: "LGTM. Reviewed-by: Lee Jones <lee@kernel.org>"
- Jiri Kosina: "Applied, thanks."
- **No reviewer suggested `Cc: stable`**. No NAKs, no concerns raised.
**Step 4.5: Stable-list discussion**
Record: No evidence of prior stable-list discussion for this particular
bug.
### PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions in diff**
Record: Only `hidpp_ff_work_handler()` (switch case
`HIDPP_FF_DESTROY_EFFECT`).
**Step 5.2: Callers / trigger path**
Record: `hidpp_ff_work_handler` is the workqueue callback scheduled by
`hidpp_ff_queue_work()`. The DESTROY path is queued by
`hidpp_ff_erase_effect()` (line 2712), which is assigned to `ff->erase`
(line 2877). `ff->erase` is the standard input-layer callback invoked
when userspace calls `EVIOCRMFF` ioctl on `/dev/input/eventX` of the FF
device. So the buggy code is reachable via a standard userspace ioctl on
any user with access to the device node (typically needs `input` group
membership, or root).
**Step 5.3: Callees**
Record: `hidpp_ff_find_effect()` iterates `data->effect_ids[]` and
returns `i+1` if found, `0` otherwise. The return value `0` directly
causes the `params[0]-1 = -1` OOB when the destroy command proceeds.
**Step 5.4: Reachability**
Record: Buggy path is reachable from userspace: `EVIOCRMFF` ioctl →
`ff->erase` → `hidpp_ff_erase_effect` →
`hidpp_ff_queue_work(HIDPP_FF_DESTROY_EFFECT)` → workqueue →
`hidpp_ff_work_handler`. Needs a Logitech HID++ FF-capable device (e.g.,
G920 wheel) and a userspace condition that erases an effect not present
in the driver's tracking array (race between operations, stale
effect_id, or autocenter destroy before upload).
**Step 5.5: Similar patterns**
Record: The same function already has the correct pattern in
`HIDPP_FF_DOWNLOAD_EFFECT` (lines 2494-2502): `slot =
response.fap.params[0]; if (slot > 0 && slot <= data->num_effects) { ...
}`. This fix brings DESTROY into symmetry with DOWNLOAD.
### PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
**Step 6.1: Buggy code in stable trees?**
Record: The buggy code was added in v4.6 (Jan 2016) and is virtually
unchanged since then (blame shows only a whitespace/comment tweak in
2024). Present in every supported stable tree: 5.4.y, 5.10.y, 5.15.y,
6.1.y, 6.6.y, 6.12.y, 6.19.y.
**Step 6.2: Backport complications**
Record: Minimal. Recent churn in the function: Yan Zhen (2024, comment
typo fix) and Lee Jones (2026, adjacent UAF fix in init path - not this
function). The switch statement body targeted by this patch is identical
to what has been in the tree since 2016. Clean apply expected on all
stable branches, modulo trivial context adjustments.
**Step 6.3: Related fixes in stable**
Record: No prior fix for this specific OOB. Some adjacent FF hardening
(UAF fix `f7a4c78bfeb32`) exists in mainline but also lacks Cc: stable.
### PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: Subsystem criticality**
Record: `drivers/hid/hid-logitech-hidpp.c` - HID driver for specific
Logitech HID++ devices (G920 wheel, MX mice, etc.). Classification:
PERIPHERAL (hardware-specific driver), but FF is a userspace-reachable
subsystem where games commonly issue erase/upload ioctls, so realistic
number of users on systems with a G920/G923 wheel.
**Step 7.2: Subsystem activity**
Record: Actively developed, with a mix of feature additions (new device
support) and security hardening (see Günther Noack's string of commits).
Mature codebase.
### PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected users**
Record: Users of Logitech HID++ FF-capable devices (G920/G923 wheels and
similar). Not universal - driver-specific. Requires the device to be
plugged in and a userspace FF client (game, test tool, etc.).
**Step 8.2: Trigger conditions**
Record: Author states "requires action both from the USB device and from
userspace." In practice: userspace invokes `EVIOCRMFF` with an effect_id
that the driver cannot find in `data->effect_ids[]` (e.g., effect never
uploaded, already erased, or device returned unexpected slot) AND the
device responds successfully to the destroy command. Not triggerable by
an unprivileged attacker alone; requires access to the evdev node.
**Step 8.3: Failure mode**
Record: Out-of-bounds write of the fixed value `-1` (`0xFFFFFFFF`) at
index `-1` of the `kzalloc`ed `data->effect_ids[]` array (an `int *`).
This corrupts 4 bytes immediately before the allocation - likely slab
metadata / redzone or an adjacent slab object. Severity: HIGH (memory
corruption), but with limited exploitability because (a) both value and
offset are fixed (not attacker-controlled), (b) requires non-trivial
combination of device + userspace state. Not directly security-critical
as a remote/local privilege escalation primitive, but an unambiguous
memory-safety bug.
**Step 8.4: Benefit/risk**
Record:
- BENEFIT: Fixes a 10-year-old memory-corruption bug in a userspace-
reachable code path. Medium-low because the trigger is narrow, but
non-zero - silent slab corruption can manifest as hard-to-debug
crashes.
- RISK: Extremely low. 9-line purely additive bounds-check that mirrors
an existing check in the same function. Zero regression potential on
normal operation.
- Ratio: Low benefit but near-zero risk → favorable for stable.
### PHASE 9: FINAL SYNTHESIS
**Evidence FOR backporting:**
- Clear out-of-bounds memory write (OOB pattern - recognized stable
category).
- Bug present in all stable trees since v4.6 (2016).
- Fix is 9 lines, in a single function, obviously correct.
- Mirrors existing defensive check in the same function
(`HIDPP_FF_DOWNLOAD_EFFECT`).
- Reviewed by Lee Jones; applied by HID maintainer Jiri Kosina.
- Author is a security-focused developer doing ongoing HID hardening.
- Clean apply expected on all stable branches.
- Zero regression risk.
**Evidence AGAINST backporting:**
- Author explicitly noted reduced exploitability ("requires action both
from the USB device and from userspace").
- Author did NOT include `Cc: stable@vger.kernel.org`, despite including
it on several similar HID hardening commits in the same timeframe.
This is a deliberate signal from a stable-aware author.
- No `Fixes:` tag, no bug report, no syzbot/KASAN evidence of real-world
triggers.
- Trigger requires specific hardware (Logitech FF wheel) + specific
userspace sequence.
- Bug has been present 10 years without reported user impact.
**Stable rules checklist:**
1. Obviously correct and tested? YES - mirrors existing pattern;
reviewed and applied.
2. Fixes a real bug? YES - OOB write is a real memory-safety bug.
3. Important issue? BORDERLINE - memory corruption but with narrow, non-
attacker-controlled trigger.
4. Small and contained? YES - 9 insertions, 6 deletions, one function.
5. No new features? YES - pure defensive check.
6. Applies cleanly? YES - expected clean on all active stable branches.
**Exception categories:** Not applicable (not a device-
ID/quirk/DT/build/doc fix).
**Decision rationale:**
This is a borderline case. Technically, it is a legitimate memory-safety
fix for a bug in userspace-reachable code that has been in the tree for
a decade. The patch is small, obviously correct, and zero-risk. OOB
writes are a canonical stable-backport category per the rule set.
The strongest counter-signal is the author's deliberate omission of `Cc:
stable` while including it on peer hardening patches, combined with the
explicit statement about limited exploitability. However, per the task
instructions, the absence of `Cc: stable` is explicitly NOT a negative
signal, and the technical criteria for stable are met.
Weighing the risk (near-zero) against the benefit (fixes a real OOB
write, even if rarely triggered), this is the kind of defensive bounds-
check fix that stable trees routinely accept. Memory corruption with a
hardcoded value at a hardcoded offset is still memory corruption.
### Verification
- [Phase 1] Parsed tags from commit message: found Signed-off-by (Noack,
Kosina), Reviewed-by (Jones), Cc (Jones). No `Cc: stable`, no
`Fixes:`, no `Reported-by:`, no `Link:`.
- [Phase 2] Diff analysis: 9 lines added, 6 removed, single file, single
function (`hidpp_ff_work_handler`), single case
(`HIDPP_FF_DESTROY_EFFECT`). Confirmed by `git show e606d8329be1e`.
- [Phase 2] Confirmed symmetry with existing check in
`HIDPP_FF_DOWNLOAD_EFFECT` by reading `drivers/hid/hid-logitech-
hidpp.c` lines 2493-2511.
- [Phase 3] `git blame -L 2502,2515 drivers/hid/hid-logitech-hidpp.c`:
buggy code introduced by `ff21a635dd1a9c` (Edwin Velds, 2016-01-11).
- [Phase 3] `git describe --contains ff21a635dd1a9c`:
`v4.6-rc1~107^2^4~1` (present since v4.6, 2016).
- [Phase 3] `git log --author="gnoack@google.com" --oneline`: confirmed
author's pattern of HID hardening work, including `Cc: stable`-tagged
peer commits (`17abd396`, `cee8337e`, `1547d41f`).
- [Phase 4] `b4 dig -c e606d8329be1e`: matched single thread at
`lore.kernel.org/all/20260331074052.194064-1-gnoack@google.com/`.
- [Phase 4] `b4 dig -a`: only v1 was posted - no revisions.
- [Phase 4] `b4 dig -w`: recipients include HID maintainers (Kosina,
Tissoires) and linux-input.
- [Phase 4] Read saved mbox `/tmp/hidpp_thread.mbox`: Lee Jones gave
Reviewed-by, Jiri Kosina said "Applied, thanks." No stable request or
concerns raised.
- [Phase 5] Confirmed reachability: `hidpp_ff_erase_effect()` wired to
`ff->erase` (line 2877), reachable via `EVIOCRMFF` ioctl. Confirmed
`hidpp_ff_find_effect` returns 0 when effect not found (line 2457).
- [Phase 5] Confirmed the buggy `params[0]-1 = -1` path when the
returned slot is 0.
- [Phase 6] Confirmed `ff21a635dd1a9c` pre-dates all active stable
branches (branch points are all after v4.6).
- [Phase 7] Subsystem `drivers/hid/` - PERIPHERAL driver for specific
Logitech HID++ devices with FF.
- [Phase 8] Failure mode: OOB write of fixed value `-1` at fixed offset
`-1` → slab corruption, severity HIGH but limited exploitability
primitive.
- UNVERIFIED: Did not run per-branch apply test on each stable tree, but
the function body is unchanged since 2016 so clean apply is highly
likely.
- UNVERIFIED: Could not find any user-reported crash or bug report
pointing to this specific OOB (no bug-tracker links in the commit
message or on the mailing list).
The fix is small, obviously correct, low-risk, and addresses a real out-
of-bounds write in a userspace-reachable path. Even with the author's
deliberate omission of `Cc: stable`, the technical stable criteria are
met, and bounds-check fixes of this nature are routinely backported.
**YES**
drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d1dea7297712d..5f63f1d2303a0 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
}
break;
case HIDPP_FF_DESTROY_EFFECT:
- if (wd->effect_id >= 0)
- /* regular effect destroyed */
- data->effect_ids[wd->params[0]-1] = -1;
- else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
- /* autocenter spring destroyed */
- data->slot_autocenter = 0;
+ slot = wd->params[0];
+ if (slot > 0 && slot <= data->num_effects) {
+ if (wd->effect_id >= 0)
+ /* regular effect destroyed */
+ data->effect_ids[slot-1] = -1;
+ else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
+ /* autocenter spring destroyed */
+ data->slot_autocenter = 0;
+ }
break;
case HIDPP_FF_SET_GLOBAL_GAINS:
data->gain = (wd->params[0] << 8) + wd->params[1];
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.6] HID: logitech-hidpp: fix race condition when accessing stale stack pointer
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Benoît Sevens, Jiri Kosina, Sasha Levin, jikos, bentiss,
linux-input, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Benoît Sevens <bsevens@google.com>
[ Upstream commit e2aaf2d3ad92ac4a8afa6b69ad4c38e7747d3d6e ]
The driver uses hidpp->send_receive_buf to point to a stack-allocated
buffer in the synchronous command path (__do_hidpp_send_message_sync).
However, this pointer is not cleared when the function returns.
If an event is processed (e.g. by a different thread) while the
send_mutex is held by a new command, but before that command has
updated send_receive_buf, the handler (hidpp_raw_hidpp_event) will
observe that the mutex is locked and dereference the stale pointer.
This results in an out-of-bounds access on a different thread's kernel
stack (or a NULL pointer dereference on the very first command).
Fix this by:
1. Clearing hidpp->send_receive_buf to NULL before releasing the mutex
in the synchronous command path.
2. Moving the assignment of the local 'question' and 'answer' pointers
inside the mutex_is_locked() block in the handler, and adding
a NULL check before dereferencing.
Signed-off-by: Benoît Sevens <bsevens@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information to make a thorough analysis. Let me
compile my findings.
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Parse Subject Line**
- Record: Subsystem `HID: logitech-hidpp`, action verb `fix`, summary:
race condition when accessing stale stack pointer (clear bug fix).
**Step 1.2: Parse Tags**
- Record: `Signed-off-by: Benoît Sevens <bsevens@google.com>` (author)
and `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID subsystem
maintainer). No Reported-by/Link/Fixes tags. No stable tag. Author is
a known Google security researcher (has other HID UAF/OOB fixes in
roccat and wacom).
**Step 1.3: Analyze Body**
- Record: Bug description: `hidpp->send_receive_buf` is assigned to
point at a stack-allocated response buffer inside
`__do_hidpp_send_message_sync()` but never cleared when the function
returns. Meanwhile `hidpp_raw_hidpp_event()` speculatively reads this
pointer whenever `send_mutex` is locked. The race:
1. Thread A finishes a command; leaves `send_receive_buf` pointing at
A's stack.
2. Thread B grabs `send_mutex`; there is a window before B writes
`send_receive_buf = response`.
3. Event handler fires (different thread), sees the mutex locked,
dereferences the stale pointer from A's stack. The handler even
performs `*answer = *report` — a WRITE to the stale stack pointer
using device-supplied data (potential stack corruption / info leak
/ exploit primitive).
4. On very first use, `send_receive_buf` is NULL → NULL deref.
Symptom: OOB stack access on a different thread or NULL deref on
first command.
**Step 1.4: Hidden Bug Detection**
- Record: Not hidden — commit title already says "fix race condition".
Classic race + UAF/stale-pointer bug.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Record: One file changed (`drivers/hid/hid-logitech-hidpp.c`), +17/-7
lines. Two functions touched: `__do_hidpp_send_message_sync()` and
`hidpp_raw_hidpp_event()`. Classification: single-file surgical fix.
**Step 2.2: Code Flow Change**
- Record: Producer (`__do_hidpp_send_message_sync`): early returns
converted to `goto out`, new `out:` label clears
`hidpp->send_receive_buf = NULL` before returning. Consumer
(`hidpp_raw_hidpp_event`): `question/answer` assignments moved inside
the `mutex_is_locked()` block, plus `if (!question) return 0;` NULL
guard before use.
**Step 2.3: Bug Mechanism**
- Record: Category (b)+(d) — race / memory safety fix. Adds implicit
synchronization by ensuring the shared pointer is NULL'd while still
holding `send_mutex`, and adds a NULL check on the read side to close
the small window between mutex acquisition and pointer assignment.
Addresses two failure modes: stale stack pointer dereference (UAF of
stack memory) and NULL dereference on first use.
**Step 2.4: Fix Quality**
- Record: Obviously correct. Minimal. No new locks, no API/ABI changes.
Possible (extremely minor) regression risk: if a report raced in
between `mutex_lock` and the assignment, the early-out `return 0` will
now skip matching it against the question — but this was already
broken (it used a stale pointer) and the send path has a 5-second
timeout with retry, so the benign behavior is strictly safer. No
regression risk beyond that.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- Record: The stale-pointer pattern (`hidpp->send_receive_buf =
response;` and the speculative read `struct hidpp_report *question =
hidpp->send_receive_buf;`) dates to commit `2f31c52529103d` "HID:
Introduce hidpp" by Benjamin Tissoires, Sep 2014 (≈ v3.18). Bug is
therefore present in every stable tree from v3.18 through
v6.19/mainline.
**Step 3.2: Fixes: tag**
- Record: No `Fixes:` tag in the commit. Manually identified introducing
commit as `2f31c52529103d` (original driver introduction, 2014).
**Step 3.3: Related Changes to the File**
- Record: Recent file history shows actively maintained file (device ID
adds, quirks, other UAF fix `f7a4c78b` "Prevent use-after-free on
force feedback initialisation failure"). Function was split into
`__do_hidpp_send_message_sync`/`hidpp_send_message_sync` in
`60165ab774cb0c` (v6.7, Jul 2023). Before that split (v6.6 is the
earliest with `__do_hidpp_send_message_sync`), the logic lived inline
in `hidpp_send_message_sync`.
**Step 3.4: Author's Other Commits**
- Record: Benoît Sevens (Google) has prior HID security fixes:
`d802d848` (roccat UAF), `2f1763f6` (wacom OOB), plus similar fixes in
uvcvideo and ALSA. Consistent pattern of Google-originated kernel
security research. High trust.
**Step 3.5: Dependencies**
- Record: Self-contained, no prerequisites. Fix only touches one file
and two functions. For v6.1.y and older the function was not yet
split, so the fix requires trivial rewording to apply (move the NULL-
out before `mutex_unlock` in `hidpp_send_message_sync`), but the
change is mechanical.
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Original Discussion**
- Record: `b4 dig -c e2aaf2d3ad92a` found the thread at https://lore.ker
nel.org/all/20260401144811.1242722-1-bsevens@google.com/. Only one
version (v1) was posted; no review-imposed revisions.
**Step 4.2: Reviewers**
- Record: `b4 dig -w`: patch CC'd `Filipe Laíns`, `Bastien Nocera`,
`Jiri Kosina`, `Benjamin Tissoires`, linux-input, linux-kernel — all
the correct maintainers. Merged by Jiri Kosina (subsystem maintainer)
with note: "Now applied. Benjamin had some ideas on further cleanup
(allocating with __free__ instead of using stack pointer), but that'd
be a little bigger cleanup, so let's keep that separate." Confirms
maintainer reviewed and accepted; any follow-up is an orthogonal
cleanup, not a fix correction.
**Step 4.3: Bug Reports**
- Record: No Reported-by or Link tags. Author is from Google — likely
discovered via internal audit/fuzzing. No public reproducer cited.
**Step 4.4: Related Series**
- Record: Single standalone patch, no series.
**Step 4.5: Stable ML**
- Record: Not searched; the patch was only posted April 1, 2026 and
applied soon after — too fresh for independent stable ML activity.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Key Functions**
- Record: `__do_hidpp_send_message_sync` (producer) and
`hidpp_raw_hidpp_event` (consumer).
**Step 5.2: Callers**
- Record: 45 call sites for `hidpp_send_*_sync` inside the driver —
every HID++ query (battery, connect, feature discovery, probe,
get_report_length, etc.). `hidpp_raw_hidpp_event` is invoked from
`hidpp_raw_event` (registered as `.raw_event` in `hid_ll_driver`),
reached from the HID core for every HID report coming from any
Logitech HID++ device (receivers, mice, keyboards, touchpads). Both
paths fire during normal operation — not rare.
**Step 5.3: Callees**
- Record: Sync path calls `__hidpp_send_report()` (USB/Bluetooth
transmit) and `wait_event_timeout()`. Event path does a struct-copy
`*answer = *report` — this is the dangerous write when `answer` is
stale.
**Step 5.4: Reachability**
- Record: The sync path runs in process context (probe, sysfs,
workqueue). The event path runs from HID input processing (URB
completion / BT callback, softirq or kthread depending on transport).
Different contexts on different CPUs → true concurrent race possible.
Triggers do not require privilege — any HID++ device that sends
unsolicited reports while a command is in flight can race. This is the
normal mode of operation for hidpp devices (connect events, battery
notifications, keypresses).
**Step 5.5: Similar Patterns**
- Record: Only one occurrence of `send_receive_buf` in the file; pattern
is unique to this driver.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable**
- Record: Verified via `git show <tag>:drivers/hid/hid-logitech-hidpp.c`
that the exact same vulnerable pattern (`send_receive_buf = response`
without clearing, `question = hidpp->send_receive_buf` read without
NULL check) exists in v4.19, v5.4, v5.10, v5.15, v6.1, v6.6. All
active stable trees are affected.
**Step 6.2: Backport Complications**
- Record: v6.6+ (and mainline): patch applies cleanly — identical
function structure. v6.1 and earlier: `__do_hidpp_send_message_sync`
does not yet exist; the logic is inline in `hidpp_send_message_sync`
which also holds/releases `send_mutex`. Backport requires mechanically
placing `hidpp->send_receive_buf = NULL;` before
`mutex_unlock(&hidpp->send_mutex)` in `hidpp_send_message_sync`, and
applying the event-handler hunk unchanged. Straightforward for the
stable maintainers.
**Step 6.3: Related Fixes in Stable**
- Record: No prior independent fix for this specific race is in stable.
Unrelated recent fixes (force-feedback UAF `f7a4c78b`) target other
paths.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Criticality**
- Record: Subsystem: `drivers/hid/` HID++ Logitech driver. Logitech
Unifying receivers/MX mice/keyboards are ubiquitous on laptops and
desktops; the driver ships on most distributions. Classification:
IMPORTANT (wide hardware user base), not CORE.
**Step 7.2: Activity**
- Record: Actively developed — multiple merges per release cycle (device
IDs, quirks, bug fixes). Mature core codepaths in the driver have been
stable for years.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Who Is Affected**
- Record: Anyone with a Logitech HID++ device (mice, keyboards,
receivers, presenters) using the in-tree driver. Essentially most
laptop users with Logitech peripherals. Driver-specific but very
widespread hardware.
**Step 8.2: Trigger Conditions**
- Record: Requires concurrent activity: one thread invoking a sync
command while the device sends an asynchronous report. Races happen
during connect/disconnect, battery reporting, feature queries. The
very-first-use path yields NULL deref (no concurrency needed: any
async event before any sync command completes once) — but that path is
rare because probe typically drives the first sync command before any
report arrives. Attacker plane: a malicious or faulty HID device can
flood reports to widen the window — reachable from device-trust
boundary, relevant for BadUSB-style threat models.
**Step 8.3: Failure Mode Severity**
- Record: (a) NULL pointer dereference → kernel oops (CRITICAL: crash).
(b) Stale stack pointer read → OOB read (HIGH: info leak). (c) Stale
stack pointer WRITE via `*answer = *report` using device-controlled
data → stack corruption on an unrelated thread (CRITICAL: memory
corruption, potential privilege escalation/exploit primitive). Overall
severity: CRITICAL.
**Step 8.4: Risk/Benefit**
- Record: Benefit HIGH — closes a long-standing race with
crash/corruption potential in a widely-deployed driver. Risk LOW —
24-line surgical change, no new locking, no API change, reviewed and
applied by subsystem maintainer, only risk is a missed-answer timeout
that already has retry logic and a 5-second wait. Ratio clearly favors
backporting.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
- FOR: Fixes real race/UAF/NULL-deref, very widespread hardware, small
and surgical, author has security-fix track record, applied by
subsystem maintainer, bug is 10+ years old (present in every active
stable), failure modes include potential stack corruption from device-
controlled data (security-relevant).
- AGAINST: No Reported-by/Fixes/Cc: stable tag; no public reproducer;
for older stables (≤v6.1) a trivial mechanical adaptation is needed
because the function was later split.
- UNRESOLVED: Exact kernel trigger rate in the wild is not documented;
CVE status unknown.
**Step 9.2: Stable Rules**
1. Obviously correct & tested? Yes — tiny, mechanical; applied by
maintainer.
2. Fixes real bug? Yes — race + stale/NULL pointer deref with concrete
failure modes.
3. Important? Yes — kernel oops and potential stack corruption.
4. Small & contained? Yes — 24 lines, one file, two functions.
5. No new features/APIs? Correct — pure fix.
6. Applies to stable? v6.6+: clean. ≤v6.1: needs trivial adaptation.
**Step 9.3: Exceptions**
- Not an exception category; qualifies on normal bug-fix merit.
**Step 9.4: Decision**
- The commit is a textbook stable candidate: small, targeted race fix in
a broadly used driver, repairing a NULL-deref + stale-pointer write
that a faulty/malicious device can provoke.
### Verification
- [Phase 1] Read full commit message — no Fixes/Reported-by/Cc: stable
tags; identified bug description and two-step fix.
- [Phase 2] Read diff end-to-end; confirmed +17/-7 in one file, two
functions, classic NULL-out + NULL-check pattern with `goto out`.
- [Phase 3] `git blame` on both functions: pattern dates to
`2f31c52529103d` (2014, v3.18). Split into
`__do_hidpp_send_message_sync` at `60165ab774cb0c` (v6.7).
- [Phase 3] `git log --oneline -- drivers/hid/hid-logitech-hidpp.c`:
file is actively maintained.
- [Phase 3] `git log --oneline --author="Benoit Sevens\|Benoît Sevens"`:
confirmed author's pattern of HID/UVC/ALSA security fixes.
- [Phase 4] `b4 dig -c e2aaf2d3ad92a`: found lore thread at `https://lor
e.kernel.org/all/20260401144811.1242722-1-bsevens@google.com/`.
- [Phase 4] `b4 dig -w`: confirmed CC list includes Jiri Kosina,
Benjamin Tissoires, Filipe Laíns, Bastien Nocera, linux-input, linux-
kernel.
- [Phase 4] `b4 dig -a`: only v1 was posted; no further revisions.
- [Phase 4] Read `/tmp/hidpp_race.mbox`: confirmed maintainer Jiri
Kosina's "Now applied" reply and note about deferred cleanup idea from
Benjamin Tissoires.
- [Phase 5] `rg send_receive_buf`: confirmed only 4 references (struct
member + 1 write + 2 reads), no other use sites.
- [Phase 5] Read `hidpp_raw_event` caller: confirmed registered as
`.raw_event` and called for every HID++ short/long/very-long report
from the device.
- [Phase 6] `git show vX:drivers/hid/hid-logitech-hidpp.c` for v4.19,
v5.4, v5.10, v5.15, v6.1, v6.6: verified vulnerable pattern exists in
every stable tree.
- [Phase 6] Verified `__do_hidpp_send_message_sync` only exists from
v6.6 onward; older trees need trivial adaptation of the producer hunk.
- [Phase 8] Reviewed event handler body: `*answer = *report` is a write,
confirming the stack-corruption / write-primitive aspect (not merely
an info leak).
- UNVERIFIED: Whether a CVE was assigned; whether a public reproducer
exists; exact in-wild trigger rate.
The fix is small, surgical, reviewed by the HID maintainer, repairs a
long-standing race with crash and stack-corruption consequences
affecting extremely common Logitech hardware, and backports cleanly to
recent stables with only a mechanical adjustment needed for older ones.
**YES**
drivers/hid/hid-logitech-hidpp.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 5f63f1d2303a0..b1330d23bd2d0 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -306,21 +306,22 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
if (ret) {
dbg_hid("__hidpp_send_report returned err: %d\n", ret);
memset(response, 0, sizeof(struct hidpp_report));
- return ret;
+ goto out;
}
if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
5*HZ)) {
dbg_hid("%s:timeout waiting for response\n", __func__);
memset(response, 0, sizeof(struct hidpp_report));
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
if (response->report_id == REPORT_ID_HIDPP_SHORT &&
response->rap.sub_id == HIDPP_ERROR) {
ret = response->rap.params[1];
dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
- return ret;
+ goto out;
}
if ((response->report_id == REPORT_ID_HIDPP_LONG ||
@@ -328,10 +329,14 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
response->fap.feature_index == HIDPP20_ERROR) {
ret = response->fap.params[1];
dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
- return ret;
+ goto out;
}
- return 0;
+ ret = 0;
+
+out:
+ hidpp->send_receive_buf = NULL;
+ return ret;
}
/*
@@ -3843,8 +3848,7 @@ static int hidpp_input_configured(struct hid_device *hdev,
static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
int size)
{
- struct hidpp_report *question = hidpp->send_receive_buf;
- struct hidpp_report *answer = hidpp->send_receive_buf;
+ struct hidpp_report *question, *answer;
struct hidpp_report *report = (struct hidpp_report *)data;
int ret;
int last_online;
@@ -3854,6 +3858,12 @@ static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
* previously sent command.
*/
if (unlikely(mutex_is_locked(&hidpp->send_mutex))) {
+ question = hidpp->send_receive_buf;
+ answer = hidpp->send_receive_buf;
+
+ if (!question)
+ return 0;
+
/*
* Check for a correct hidpp20 answer or the corresponding
* error
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] media: rc: fix race between unregister and urb/irq callbacks
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Sean Young, Haotian Zhang, Patrice Chotard, Hans Verkuil,
Sasha Levin, andrzej.hajda, neil.armstrong, rfoss, airlied,
daniel, bonbons, jikos, benjamin.tissoires, hverkuil-cisco,
mchehab, maximlevitsky, wens, jernej.skrabec, samuel, david,
benpicco, crope, gregkh, dri-devel, linux-kernel, linux-input,
linux-media, linux-arm-kernel, linux-sunxi, linux-staging
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Sean Young <sean@mess.org>
[ Upstream commit dccc0c3ddf8f16071736f98a7d6dd46a2d43e037 ]
Some rc device drivers have a race condition between rc_unregister_device()
and irq or urb callbacks. This is because rc_unregister_device() does two
things, it marks the device as unregistered so no new commands can be
issued and then it calls rc_free_device(). This means the driver has no
chance to cancel any pending urb callbacks or interrupts after the device
has been marked as unregistered. Those callbacks may access struct rc_dev
or its members (e.g. struct ir_raw_event_ctrl), which have been freed by
rc_free_device().
This change removes the implicit call to rc_free_device() from
rc_unregister_device(). This means that device drivers can call
rc_unregister_device() in their remove or disconnect function, then cancel
all the urbs and interrupts before explicitly calling rc_free_device().
Note this is an alternative fix for an issue found by Haotian Zhang, see
the Closes: tags.
Reported-by: Haotian Zhang <vulab@iscas.ac.cn>
Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Good - drivers using `devm_rc_allocate_device` don't call
`rc_unregister_device` manually (they use `devm_rc_register_device`
which handles cleanup automatically). The patch removes the
`managed_alloc` flag because it changes the contract:
`rc_unregister_device` no longer frees the device regardless of how it
was allocated. Instead, `devm_rc_alloc_release` (the devres release
callback) calls `rc_free_device`, and the regular drivers must add
explicit `rc_free_device` calls.
Now let me do the full analysis write-up.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: PARSE THE SUBJECT LINE
Record: [media: rc] [fix] [race between unregister and urb/irq
callbacks]
### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Reported-by:** Haotian Zhang <vulab@iscas.ac.cn> - the reporter
found multiple race conditions
- **Closes:** 4 separate lore.kernel.org links to bug reports (Nov 2025)
- **Reviewed-by:** Patrice Chotard <patrice.chotard@foss.st.com>
- **Signed-off-by:** Sean Young <sean@mess.org> (author, RC subsystem
maintainer)
- **Signed-off-by:** Hans Verkuil <hverkuil+cisco@kernel.org> (media
subsystem maintainer)
Record: Multiple bug reports (4 Closes: tags), reviewed by a maintainer,
written by the RC subsystem maintainer, merged by the media subsystem
maintainer. No Fixes: tag (expected).
### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit explains a **use-after-free race condition**:
1. `rc_unregister_device()` marks the device as unregistered
2. Then it calls `rc_free_device()`, which frees `struct rc_dev` and
`struct ir_raw_event_ctrl`
3. Between marking unregistered and freeing, there's no window for
drivers to cancel pending URBs/IRQs
4. Those pending callbacks may still access the freed `struct rc_dev` or
its members
Record: Bug = use-after-free due to race between device unregister and
URB/IRQ callbacks. Symptom = accessing freed memory. Root cause =
`rc_unregister_device()` implicitly calls `rc_free_device()` before
drivers can cancel pending async operations.
### Step 1.4: DETECT HIDDEN BUG FIXES
This is an explicit race condition / use-after-free fix. Not hidden.
Record: This is a clear, well-documented bug fix.
## PHASE 2: DIFF ANALYSIS
### Step 2.1: INVENTORY THE CHANGES
41 files changed, ~58 insertions, ~36 deletions. Files span:
- Core: `rc-main.c`, `rc-ir-raw.c`, `rc-core.h`
- ~30+ driver files across media/rc, media/pci, media/usb, gpu/drm, hid,
staging
Record: Cross-subsystem change touching 41 files, but each driver change
is 1-3 lines. Core changes are ~10 lines net.
### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Core changes:**
1. `rc-main.c`: `rc_unregister_device()` no longer calls
`rc_free_device()` (removes the `if (!dev->managed_alloc)
rc_free_device(dev)` block)
2. `rc-main.c`: `rc_dev_release()` now calls `ir_raw_event_free(dev)`
before `kfree(dev)` - this ensures raw event data is cleaned up when
the device struct is finally freed
3. `rc-main.c`: `devm_rc_allocate_device()` no longer sets
`managed_alloc = true`
4. `rc-ir-raw.c`: `ir_raw_event_unregister()` no longer calls
`ir_raw_event_free()` (moved to `rc_dev_release`)
5. `rc-ir-raw.c`: `ir_raw_event_free()` removes the `if (!dev)` guard
(now only called from `rc_dev_release`)
6. `rc-core.h`: Removes `managed_alloc` field from `struct rc_dev`
**Driver changes:** Every driver using `rc_unregister_device()` now also
calls `rc_free_device()` afterward. Some USB drivers also reorder
operations to call `rc_unregister_device()` BEFORE killing URBs, then
`rc_free_device()` AFTER killing URBs.
### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Race condition / Use-after-free**
Before the fix:
```
rc_unregister_device()
-> marks device unregistered
-> calls rc_free_device() -> frees struct rc_dev
// URB/IRQ callbacks can still fire and access freed rc_dev!
```
After the fix:
```
rc_unregister_device()
-> marks device unregistered
// Driver cancels URBs/IRQs here
rc_free_device()
-> safely frees struct rc_dev after all callbacks cancelled
```
Record: UAF race condition fix. Separating unregister from free gives
drivers a window to cancel async operations.
### Step 2.4: ASSESS THE FIX QUALITY
- Written by Sean Young (RC subsystem maintainer)
- Reviewed by Patrice Chotard
- Merged by Hans Verkuil (media maintainer)
- The approach is sound: it separates two concerns (marking unregistered
vs. freeing memory)
- Each per-driver change is trivial (add one `rc_free_device()` line)
- **Concern:** The scope is very large (41 files), though each change is
trivially mechanical
Record: High quality fix from the subsystem maintainer. Regression risk
is low per-driver but the sheer breadth is notable. The error path
changes in probe functions (removing `rdev = NULL` after
`rc_unregister_device`) are now correct because `rc_free_device(rdev)`
on the next goto target will properly free even after unregister.
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: BLAME THE CHANGED LINES
The `managed_alloc` logic was introduced in commit `ddbf7d5a698c4d`
(2016, v4.10 era) by Heiner Kallweit. The implicit `rc_free_device()`
call in `rc_unregister_device()` has been present since `d8b4b5822f51e2`
(2010, v2.6.36 era). The race condition has existed since the very
beginning of the rc_core subsystem.
Record: Bug exists in all kernel versions since 2010 (v2.6.36+). Present
in all stable trees.
### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present (expected for autosel candidates).
### Step 3.3: CHECK FILE HISTORY
Multiple previous fixes for the same class of UAF bugs exist:
- `5abda7a16698d` "media: dm1105: Fix use after free bug in
dm1105_remove due to race condition"
- `29b0589a865b6` "media: rc: Fix use-after-free bugs caused by
ene_tx_irqsim()"
These were individual driver fixes for the same systemic issue. This
patch fixes it once and for all in the core.
Record: This is a systemic fix replacing multiple individual driver-
level workarounds.
### Step 3.4: CHECK THE AUTHOR
Sean Young is the RC subsystem maintainer. He has dozens of commits in
`drivers/media/rc/`. This is his subsystem.
Record: Author is the subsystem maintainer - highest trust level.
### Step 3.5: CHECK FOR DEPENDENCIES
This is a single, self-contained patch. All changes are coordinated. No
other patches are needed.
Record: Standalone fix, no dependencies.
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Found via web search:
- v1: "[PATCH] media: rc: rc_unregister_device() should not call
rc_free_device()" (Dec 20, 2025)
- v2: "[PATCH v2] media: rc: fix race between unregister and urb/irq
callbacks" (Jan 26, 2026)
The v2 has the `Reviewed-by` tag from Patrice Chotard that v1 didn't
have.
Record: Patch went through 2 revisions. Applied version is v2 (latest).
Reviewed by maintainer.
### Step 4.2: WHO REVIEWED
- Reviewed-by: Patrice Chotard (STMicroelectronics, works on st_rc
driver)
- Signed-off-by: Hans Verkuil (media subsystem co-maintainer)
- CC'd: Numerous subsystem maintainers (Maarten Lankhorst, David Airlie
for DRM, etc.)
Record: Properly reviewed through the maintainer chain.
### Step 4.3: SEARCH FOR THE BUG REPORT
4 separate bug reports from Haotian Zhang (November 2025) about UAF
races in different RC drivers.
Record: Multiple independent bug reports confirm this is a real-world
issue.
### Step 4.4: RELATED PATCHES
This is the alternative/comprehensive fix. The original individual
patches from Haotian Zhang addressed each driver separately; Sean
Young's approach fixes the root cause in the core.
Record: This is the definitive fix rather than per-driver workarounds.
### Step 4.5: STABLE MAILING LIST
No specific stable discussion found. The patch does not have Cc: stable
tag.
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: KEY FUNCTIONS
- `rc_unregister_device()` - modified to remove implicit free
- `rc_free_device()` - now must be called explicitly by drivers
- `rc_dev_release()` - now frees raw event data
- `ir_raw_event_free()` - moved from unregister path to release path
- `ir_raw_event_unregister()` - no longer frees raw events
### Step 5.2: CALLERS
Every RC driver's remove/disconnect/exit function calls
`rc_unregister_device()`. The patch adds `rc_free_device()` to all of
them. This affects USB IR receivers, PCI TV tuner cards, embedded IR
receivers, DRM bridges, etc.
Record: Broad impact - every RC device driver is affected.
### Step 5.3-5.5: CALL CHAIN AND PATTERNS
The race is triggered during device removal (USB disconnect, PCI remove,
platform remove). This is a common path triggered by:
- USB device physical disconnect
- Module unload
- System shutdown
- Device unbind via sysfs
Record: The buggy path is easily triggered by physical device
disconnect. Not theoretical.
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE?
Yes. The buggy code in `rc_unregister_device()` (calling
`rc_free_device()` implicitly) has existed since 2010. It is present in
ALL stable trees.
Record: Bug affects all stable trees (6.6.y, 6.1.y, 5.15.y, etc.).
### Step 6.2: BACKPORT COMPLICATIONS
This patch touches 41 files. Some files may have diverged between
mainline and stable trees. Backporting will likely require resolving
minor conflicts in some drivers. The core changes to `rc-main.c`, `rc-
ir-raw.c`, and `rc-core.h` are critical and should apply with minor
fuzz. The per-driver changes are mechanical and can be adapted.
Record: Expected difficulty: **medium**. Core changes likely apply
cleanly. Some driver-specific changes may need minor adjustment due to
driver-specific changes in stable trees vs mainline.
### Step 6.3: RELATED FIXES IN STABLE
Individual UAF fixes like `5abda7a16698d` (dm1105) and `29b0589a865b6`
(ene_ir) may already be in some stable trees, but they only fix specific
drivers. This systemic fix is comprehensive.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: SUBSYSTEM CRITICALITY
Media/RC subsystem - used by IR receivers on:
- TV tuner cards (USB and PCI)
- Media center remotes (iMON, MCE, Xbox)
- Embedded IR receivers (sunxi, meson, hix5hd2)
- DRM bridges with CEC/RC
Record: IMPORTANT level - affects users of IR remote control hardware
(common in HTPCs, embedded media devices).
### Step 7.2: SUBSYSTEM ACTIVITY
Active subsystem with regular maintenance from Sean Young.
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: WHO IS AFFECTED
All users with IR remote control hardware who disconnect or unbind the
device. This includes USB IR receivers (very common for HTPC setups),
PCI TV tuner cards with IR, and embedded systems with hardware IR.
Record: Moderate user population - anyone using Linux with IR remote
control hardware.
### Step 8.2: TRIGGER CONDITIONS
- Physical USB disconnect of IR receiver
- Module unload while IR device active
- Device unbind via sysfs
- System shutdown with pending IR operations
- Concurrent with incoming IR data
Record: Common trigger conditions. USB disconnect is the most frequent.
### Step 8.3: FAILURE MODE SEVERITY
Use-after-free: Accessing freed `struct rc_dev` or `struct
ir_raw_event_ctrl` from URB/IRQ callbacks. This leads to:
- Kernel crash/oops (most likely)
- Memory corruption (possible)
- Security vulnerability (potential, if attacker controls USB device)
Record: Severity: HIGH to CRITICAL. UAF can cause crashes and is
potentially exploitable.
### Step 8.4: RISK-BENEFIT RATIO
**Benefit:** HIGH - Fixes use-after-free race in all RC drivers
systemically. Prevents crashes during device disconnect. Fixes reported
real-world bug.
**Risk:** MEDIUM - 41 files touched, but each change is 1-3 lines and
mechanically identical (add `rc_free_device()` after
`rc_unregister_device()`). The core API change is well-designed. Some
USB drivers also reorder operations to call `rc_unregister_device()`
before `usb_kill_urb()`, which is the correct order.
Record: Benefit HIGH, Risk MEDIUM. The fix is well-designed but the
scope is large.
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: COMPILE THE EVIDENCE
**Evidence FOR backporting:**
- Fixes a real use-after-free race condition
- Multiple independent bug reports (4 Closes: tags)
- Written and signed by the RC subsystem maintainer (Sean Young)
- Reviewed by Patrice Chotard, merged by Hans Verkuil
- Bug has existed since 2010, affects all stable trees
- Previous individual driver fixes confirm this is a known issue pattern
- UAF can cause kernel crashes and is potentially exploitable
- The fix is logically correct - it separates unregister from free
**Evidence AGAINST backporting:**
- Very large scope: 41 files modified across multiple subsystems
- Changes a core API contract (rc_unregister_device no longer frees)
- Risk of backport conflicts due to per-driver divergence between
mainline and stable
- Some drivers may not exist in older stable trees, requiring manual
adaptation
- Removes `managed_alloc` infrastructure, affecting
`devm_rc_allocate_device()` users
### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - reviewed by maintainers,
applied to mainline
2. Fixes a real bug? **YES** - UAF race condition with 4 bug reports
3. Important issue? **YES** - use-after-free / crash during device
disconnect
4. Small and contained? **NO** - 41 files is very large. However, each
change is mechanical (1-3 lines per file) and the core change is
small (~10 lines)
5. No new features or APIs? **YES** - only changes existing API behavior
6. Can apply to stable trees? **PARTIALLY** - core changes likely apply;
some driver changes may need adaptation
### Step 9.3: EXCEPTION CATEGORIES
Not applicable - this is a bug fix, not a device ID/quirk/DT/build fix.
### Step 9.4: DECISION
This is a genuine, important use-after-free fix from the subsystem
maintainer with multiple independent bug reports. However, the **scope
is extremely large** (41 files across multiple subsystems) and it
changes a core API contract. While each individual change is trivial and
mechanical, the sheer number of files makes this a high-risk backport.
If even one driver is missed or adapted incorrectly, it introduces a new
bug (memory leak from missing `rc_free_device()` or double-free from
calling it when not needed).
The stable kernel rules explicitly require patches to be "small and
contained." While the fix itself is correct and important, 41 files
touching DRM, HID, media PCI, media USB, and staging subsystems is not
small and contained. A backport of this magnitude would need careful
manual review for each stable tree to handle driver-specific divergence.
Verification:
- [Phase 1] Parsed tags: Reported-by: Haotian Zhang, 4 Closes: links,
Reviewed-by: Patrice Chotard, Signed-off-by: Sean Young (author/RC
maintainer), Hans Verkuil (media maintainer)
- [Phase 2] Diff analysis: 41 files changed, core change removes
implicit rc_free_device() from rc_unregister_device(), each driver
adds explicit rc_free_device() call
- [Phase 2] Verified: Current rc_unregister_device() at line 2046 has
`if (!dev->managed_alloc) rc_free_device(dev)` - confirmed the bug
exists
- [Phase 2] Verified: rc_dev_release() at line 1610 currently just does
`kfree(dev)` without freeing raw events - patch adds
ir_raw_event_free(dev) there
- [Phase 3] git blame: rc_unregister_device() implicit free from
d8b4b5822f51e2 (2010, v2.6.36), managed_alloc from ddbf7d5a698c4d
(2016, v4.10)
- [Phase 3] git show ddbf7d5a698c4d: confirmed managed_alloc was
introduced by Heiner Kallweit in 2016
- [Phase 3] Found related individual driver UAF fixes: 5abda7a16698d
(dm1105), 29b0589a865b6 (ene_ir)
- [Phase 3] git show 5abda7a16698d: confirmed dm1105 UAF race diagram
showing exactly the same pattern
- [Phase 4] Web search found v1 and v2 submissions: v1 Dec 2025, v2 Jan
26 2026
- [Phase 4] Found full v2 patch on freedesktop.org archives - matches
commit
- [Phase 4] 4 separate bug reports from Haotian Zhang (Nov 2025) confirm
real-world issue
- [Phase 5] Verified devm_rc_allocate_device callers (gpio-ir-recv,
meson-ir, etc.) don't manually call rc_unregister_device - they use
devm path, so they're unaffected
- [Phase 6] Bug exists since v2.6.36 (2010) - present in all stable
trees
- [Phase 8] Trigger: USB device disconnect during IR activity - common
operation
- UNVERIFIED: Whether all 41 files exist in all stable trees (some
drivers may have been added/removed between releases)
This is a borderline case. The fix addresses a real, reported use-after-
free bug from the subsystem maintainer with proper review. However, the
41-file scope makes it risky for stable. On balance, the UAF is serious
enough (crash, potential security) that it warrants backporting despite
the large scope, especially since each per-driver change is mechanically
identical and trivially verifiable.
**YES**
drivers/gpu/drm/bridge/sil-sii8620.c | 1 +
drivers/hid/hid-picolcd_cir.c | 1 +
drivers/media/cec/core/cec-core.c | 2 +-
drivers/media/common/siano/smsir.c | 1 +
drivers/media/i2c/ir-kbd-i2c.c | 2 ++
drivers/media/pci/bt8xx/bttv-input.c | 3 ++-
drivers/media/pci/cx23885/cx23885-input.c | 1 +
drivers/media/pci/cx88/cx88-input.c | 3 ++-
drivers/media/pci/dm1105/dm1105.c | 1 +
drivers/media/pci/mantis/mantis_input.c | 1 +
drivers/media/pci/saa7134/saa7134-input.c | 1 +
drivers/media/pci/smipcie/smipcie-ir.c | 1 +
drivers/media/pci/ttpci/budget-ci.c | 1 +
drivers/media/rc/ati_remote.c | 6 +++---
drivers/media/rc/ene_ir.c | 2 +-
drivers/media/rc/fintek-cir.c | 3 ++-
drivers/media/rc/igorplugusb.c | 1 +
drivers/media/rc/iguanair.c | 1 +
drivers/media/rc/img-ir/img-ir-hw.c | 3 ++-
drivers/media/rc/img-ir/img-ir-raw.c | 3 ++-
drivers/media/rc/imon.c | 3 ++-
drivers/media/rc/ir-hix5hd2.c | 2 +-
drivers/media/rc/ir_toy.c | 1 +
drivers/media/rc/ite-cir.c | 2 +-
drivers/media/rc/mceusb.c | 1 +
drivers/media/rc/rc-ir-raw.c | 5 -----
drivers/media/rc/rc-loopback.c | 1 +
drivers/media/rc/rc-main.c | 6 +-----
drivers/media/rc/redrat3.c | 4 +++-
drivers/media/rc/st_rc.c | 2 +-
drivers/media/rc/streamzap.c | 7 ++++---
drivers/media/rc/sunxi-cir.c | 1 +
drivers/media/rc/ttusbir.c | 2 +-
drivers/media/rc/winbond-cir.c | 2 +-
drivers/media/rc/xbox_remote.c | 5 +++--
drivers/media/usb/au0828/au0828-input.c | 1 +
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 1 +
drivers/media/usb/dvb-usb/dvb-usb-remote.c | 6 ++++--
drivers/media/usb/em28xx/em28xx-input.c | 1 +
drivers/staging/media/av7110/av7110_ir.c | 1 +
include/media/rc-core.h | 2 --
41 files changed, 58 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c
index d3f238b1f2a94..982306eb4f0a7 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2221,6 +2221,7 @@ static void sii8620_detach(struct drm_bridge *bridge)
return;
rc_unregister_device(ctx->rc_dev);
+ rc_free_device(ctx->rc_dev);
}
static int sii8620_is_packing_required(struct sii8620 *ctx,
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index d6faa0e00f95a..6d4c636e1c9f7 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -134,5 +134,6 @@ void picolcd_exit_cir(struct picolcd_data *data)
data->rc_dev = NULL;
rc_unregister_device(rdev);
+ rc_free_device(rdev);
}
diff --git a/drivers/media/cec/core/cec-core.c b/drivers/media/cec/core/cec-core.c
index 1953ce559ecaf..0fcd3b5e60c8d 100644
--- a/drivers/media/cec/core/cec-core.c
+++ b/drivers/media/cec/core/cec-core.c
@@ -338,8 +338,8 @@ int cec_register_adapter(struct cec_adapter *adap,
res = cec_devnode_register(&adap->devnode, adap->owner);
if (res) {
#ifdef CONFIG_MEDIA_CEC_RC
- /* Note: rc_unregister also calls rc_free */
rc_unregister_device(adap->rc);
+ rc_free_device(adap->rc);
adap->rc = NULL;
#endif
return res;
diff --git a/drivers/media/common/siano/smsir.c b/drivers/media/common/siano/smsir.c
index af07fed21ae12..283770d583d56 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -92,6 +92,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
void sms_ir_exit(struct smscore_device_t *coredev)
{
rc_unregister_device(coredev->ir.dev);
+ rc_free_device(coredev->ir.dev);
pr_debug("\n");
}
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index 5588cdd7ec20d..6047453170043 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -355,6 +355,7 @@ static void ir_work(struct work_struct *work)
mutex_unlock(&ir->lock);
if (rc == -ENODEV) {
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
ir->rc = NULL;
return;
}
@@ -972,6 +973,7 @@ static void ir_remove(struct i2c_client *client)
i2c_unregister_device(ir->tx_c);
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
}
static const struct i2c_device_id ir_kbd_id[] = {
diff --git a/drivers/media/pci/bt8xx/bttv-input.c b/drivers/media/pci/bt8xx/bttv-input.c
index 373b6c6817d76..f704476506e07 100644
--- a/drivers/media/pci/bt8xx/bttv-input.c
+++ b/drivers/media/pci/bt8xx/bttv-input.c
@@ -572,8 +572,9 @@ void bttv_input_fini(struct bttv *btv)
if (btv->remote == NULL)
return;
- bttv_ir_stop(btv);
rc_unregister_device(btv->remote->dev);
+ bttv_ir_stop(btv);
+ rc_free_device(btv->remote->dev);
kfree(btv->remote);
btv->remote = NULL;
}
diff --git a/drivers/media/pci/cx23885/cx23885-input.c b/drivers/media/pci/cx23885/cx23885-input.c
index ffbbeca8a8e5f..554767b8ef2bf 100644
--- a/drivers/media/pci/cx23885/cx23885-input.c
+++ b/drivers/media/pci/cx23885/cx23885-input.c
@@ -402,6 +402,7 @@ void cx23885_input_fini(struct cx23885_dev *dev)
if (dev->kernel_ir == NULL)
return;
rc_unregister_device(dev->kernel_ir->rc);
+ rc_free_device(dev->kernel_ir->rc);
kfree(dev->kernel_ir->phys);
kfree(dev->kernel_ir->name);
kfree(dev->kernel_ir);
diff --git a/drivers/media/pci/cx88/cx88-input.c b/drivers/media/pci/cx88/cx88-input.c
index e958eecb29c5c..5d9ce4f9af011 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -509,8 +509,9 @@ int cx88_ir_fini(struct cx88_core *core)
if (!ir)
return 0;
- cx88_ir_stop(core);
rc_unregister_device(ir->dev);
+ cx88_ir_stop(core);
+ rc_free_device(ir->dev);
kfree(ir);
/* done */
diff --git a/drivers/media/pci/dm1105/dm1105.c b/drivers/media/pci/dm1105/dm1105.c
index de05d8b0f9dc5..bbd24769ae56b 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -763,6 +763,7 @@ static int dm1105_ir_init(struct dm1105_dev *dm1105)
static void dm1105_ir_exit(struct dm1105_dev *dm1105)
{
rc_unregister_device(dm1105->ir.dev);
+ rc_free_device(dm1105->ir.dev);
}
static int dm1105_hw_init(struct dm1105_dev *dev)
diff --git a/drivers/media/pci/mantis/mantis_input.c b/drivers/media/pci/mantis/mantis_input.c
index 34c0d979240fd..edb4cacf55d22 100644
--- a/drivers/media/pci/mantis/mantis_input.c
+++ b/drivers/media/pci/mantis/mantis_input.c
@@ -72,5 +72,6 @@ EXPORT_SYMBOL_GPL(mantis_input_init);
void mantis_input_exit(struct mantis_pci *mantis)
{
rc_unregister_device(mantis->rc);
+ rc_free_device(mantis->rc);
}
EXPORT_SYMBOL_GPL(mantis_input_exit);
diff --git a/drivers/media/pci/saa7134/saa7134-input.c b/drivers/media/pci/saa7134/saa7134-input.c
index 5b71014157808..7f6680de31564 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -834,6 +834,7 @@ void saa7134_input_fini(struct saa7134_dev *dev)
return;
rc_unregister_device(dev->remote->dev);
+ rc_free_device(dev->remote->dev);
kfree(dev->remote);
dev->remote = NULL;
}
diff --git a/drivers/media/pci/smipcie/smipcie-ir.c b/drivers/media/pci/smipcie/smipcie-ir.c
index c0604d9c70119..0bbe4fa2d5a84 100644
--- a/drivers/media/pci/smipcie/smipcie-ir.c
+++ b/drivers/media/pci/smipcie/smipcie-ir.c
@@ -181,5 +181,6 @@ void smi_ir_exit(struct smi_dev *dev)
rc_unregister_device(rc_dev);
smi_ir_stop(ir);
+ rc_free_device(rc_dev);
ir->rc_dev = NULL;
}
diff --git a/drivers/media/pci/ttpci/budget-ci.c b/drivers/media/pci/ttpci/budget-ci.c
index 3709c0fb23b07..8b496b959d7ea 100644
--- a/drivers/media/pci/ttpci/budget-ci.c
+++ b/drivers/media/pci/ttpci/budget-ci.c
@@ -249,6 +249,7 @@ static void msp430_ir_deinit(struct budget_ci *budget_ci)
cancel_work_sync(&budget_ci->ir.msp430_irq_bh_work);
rc_unregister_device(budget_ci->ir.dev);
+ rc_free_device(budget_ci->ir.dev);
}
static int ciintf_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 78abe810a88e7..51d85de24fae3 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -921,7 +921,6 @@ static int ati_remote_probe(struct usb_interface *interface,
input_free_device(input_dev);
exit_unregister_device:
rc_unregister_device(rc_dev);
- rc_dev = NULL;
exit_kill_urbs:
usb_kill_urb(ati_remote->irq_urb);
usb_kill_urb(ati_remote->out_urb);
@@ -941,18 +940,19 @@ static void ati_remote_disconnect(struct usb_interface *interface)
struct ati_remote *ati_remote;
ati_remote = usb_get_intfdata(interface);
- usb_set_intfdata(interface, NULL);
if (!ati_remote) {
dev_warn(&interface->dev, "%s - null device?\n", __func__);
return;
}
+ rc_unregister_device(ati_remote->rdev);
+ usb_set_intfdata(interface, NULL);
usb_kill_urb(ati_remote->irq_urb);
usb_kill_urb(ati_remote->out_urb);
if (ati_remote->idev)
input_unregister_device(ati_remote->idev);
- rc_unregister_device(ati_remote->rdev);
ati_remote_free_buffers(ati_remote);
+ rc_free_device(ati_remote->rdev);
kfree(ati_remote);
}
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index f8120605501ab..6f7dccc965e7f 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1090,7 +1090,6 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
release_region(dev->hw_io, ENE_IO_SIZE);
exit_unregister_device:
rc_unregister_device(rdev);
- rdev = NULL;
exit_free_dev_rdev:
rc_free_device(rdev);
kfree(dev);
@@ -1110,6 +1109,7 @@ static void ene_remove(struct pnp_dev *pnp_dev)
ene_rx_restore_hw_buffer(dev);
spin_unlock_irqrestore(&dev->hw_lock, flags);
+ rc_free_device(dev->rdev);
free_irq(dev->irq, dev);
release_region(dev->hw_io, ENE_IO_SIZE);
kfree(dev);
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index f7cfa8a073ebc..5055dfc3f4651 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -568,6 +568,7 @@ static void fintek_remove(struct pnp_dev *pdev)
struct fintek_dev *fintek = pnp_get_drvdata(pdev);
unsigned long flags;
+ rc_unregister_device(fintek->rdev);
spin_lock_irqsave(&fintek->fintek_lock, flags);
/* disable CIR */
fintek_disable_cir(fintek);
@@ -580,7 +581,7 @@ static void fintek_remove(struct pnp_dev *pdev)
free_irq(fintek->cir_irq, fintek);
release_region(fintek->cir_addr, fintek->cir_port_len);
- rc_unregister_device(fintek->rdev);
+ rc_free_device(fintek->rdev);
kfree(fintek);
}
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index e034c93d57cf0..5ceb5ca44e235 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -242,6 +242,7 @@ static void igorplugusb_disconnect(struct usb_interface *intf)
usb_set_intfdata(intf, NULL);
usb_unpoison_urb(ir->urb);
usb_free_urb(ir->urb);
+ rc_free_device(ir->rc);
kfree(ir->buf_in);
}
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index c508f2536243e..0c5b8befb0af3 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -500,6 +500,7 @@ static void iguanair_disconnect(struct usb_interface *intf)
usb_set_intfdata(intf, NULL);
usb_kill_urb(ir->urb_in);
usb_kill_urb(ir->urb_out);
+ rc_free_device(ir->rc);
usb_free_urb(ir->urb_in);
usb_free_urb(ir->urb_out);
usb_free_coherent(ir->udev, MAX_IN_PACKET, ir->buf_in, ir->dma_in);
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c b/drivers/media/rc/img-ir/img-ir-hw.c
index 63f6f5b36838d..f30adf4d8444d 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -1118,9 +1118,10 @@ void img_ir_remove_hw(struct img_ir_priv *priv)
struct rc_dev *rdev = hw->rdev;
if (!rdev)
return;
+ rc_unregister_device(rdev);
img_ir_set_decoder(priv, NULL, 0);
hw->rdev = NULL;
- rc_unregister_device(rdev);
+ rc_free_device(rdev);
#ifdef CONFIG_COMMON_CLK
if (!IS_ERR(priv->clk))
clk_notifier_unregister(priv->clk, &hw->clk_nb);
diff --git a/drivers/media/rc/img-ir/img-ir-raw.c b/drivers/media/rc/img-ir/img-ir-raw.c
index 92fb7b555a0f6..f1460d4acf3e8 100644
--- a/drivers/media/rc/img-ir/img-ir-raw.c
+++ b/drivers/media/rc/img-ir/img-ir-raw.c
@@ -136,6 +136,7 @@ void img_ir_remove_raw(struct img_ir_priv *priv)
if (!rdev)
return;
+ rc_unregister_device(rdev);
/* switch off and disable raw (edge) interrupts */
spin_lock_irq(&priv->lock);
raw->rdev = NULL;
@@ -145,7 +146,7 @@ void img_ir_remove_raw(struct img_ir_priv *priv)
img_ir_write(priv, IMG_IR_IRQ_CLEAR, IMG_IR_IRQ_EDGE);
spin_unlock_irq(&priv->lock);
- rc_unregister_device(rdev);
+ rc_free_device(rdev);
timer_delete_sync(&raw->timer);
}
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 7e92161105d53..310c9fc9ae91c 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2541,9 +2541,10 @@ static void imon_disconnect(struct usb_interface *interface)
if (ifnum == 0) {
ictx->dev_present_intf0 = false;
+ rc_unregister_device(ictx->rdev);
usb_kill_urb(ictx->rx_urb_intf0);
input_unregister_device(ictx->idev);
- rc_unregister_device(ictx->rdev);
+ rc_free_device(ictx->rdev);
if (ictx->display_supported) {
if (ictx->display_type == IMON_DISPLAY_TYPE_LCD)
usb_deregister_dev(interface, &imon_lcd_class);
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index edc46828509c8..1b061e4a3dcfa 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -331,7 +331,6 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
regerr:
rc_unregister_device(rdev);
- rdev = NULL;
clkerr:
clk_disable_unprepare(priv->clock);
err:
@@ -346,6 +345,7 @@ static void hix5hd2_ir_remove(struct platform_device *pdev)
clk_disable_unprepare(priv->clock);
rc_unregister_device(priv->rdev);
+ rc_free_device(priv->rdev);
}
#ifdef CONFIG_PM_SLEEP
diff --git a/drivers/media/rc/ir_toy.c b/drivers/media/rc/ir_toy.c
index d6472de5da87d..089833e411786 100644
--- a/drivers/media/rc/ir_toy.c
+++ b/drivers/media/rc/ir_toy.c
@@ -536,6 +536,7 @@ static void irtoy_disconnect(struct usb_interface *intf)
usb_free_urb(ir->urb_out);
usb_kill_urb(ir->urb_in);
usb_free_urb(ir->urb_in);
+ rc_free_device(ir->rc);
kfree(ir->in);
kfree(ir->out);
kfree(ir);
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index bf544517c67a9..bde2a70512310 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1414,7 +1414,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id
release_region(itdev->cir_addr, itdev->params->io_region_size);
exit_unregister_device:
rc_unregister_device(rdev);
- rdev = NULL;
exit_free_dev_rdev:
rc_free_device(rdev);
kfree(itdev);
@@ -1439,6 +1438,7 @@ static void ite_remove(struct pnp_dev *pdev)
release_region(dev->cir_addr, dev->params->io_region_size);
rc_unregister_device(dev->rdev);
+ rc_free_device(dev->rdev);
kfree(dev);
}
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ed55e9ec3c570..06222eee17540 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1850,6 +1850,7 @@ static void mceusb_dev_disconnect(struct usb_interface *intf)
usb_free_urb(ir->urb_in);
usb_free_coherent(dev, ir->len_in, ir->buf_in, ir->dma_in);
usb_put_dev(dev);
+ rc_free_device(ir->rc);
kfree(ir);
}
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 2e269ef5e26be..ba24c2f22d39f 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -648,9 +648,6 @@ int ir_raw_event_register(struct rc_dev *dev)
void ir_raw_event_free(struct rc_dev *dev)
{
- if (!dev)
- return;
-
kfree(dev->raw);
dev->raw = NULL;
}
@@ -674,8 +671,6 @@ void ir_raw_event_unregister(struct rc_dev *dev)
lirc_bpf_free(dev);
- ir_raw_event_free(dev);
-
/*
* A user can be calling bpf(BPF_PROG_{QUERY|ATTACH|DETACH}), so
* ensure that the raw member is null on unlock; this is how
diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c
index 78ac09b3cbd34..53d0540717b36 100644
--- a/drivers/media/rc/rc-loopback.c
+++ b/drivers/media/rc/rc-loopback.c
@@ -263,6 +263,7 @@ static int __init loop_init(void)
static void __exit loop_exit(void)
{
rc_unregister_device(loopdev.dev);
+ rc_free_device(loopdev.dev);
}
module_init(loop_init);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 821607504008a..dda3479ea3add 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1611,6 +1611,7 @@ static void rc_dev_release(struct device *device)
{
struct rc_dev *dev = to_rc_dev(device);
+ ir_raw_event_free(dev);
kfree(dev);
}
@@ -1773,7 +1774,6 @@ struct rc_dev *devm_rc_allocate_device(struct device *dev,
}
rc->dev.parent = dev;
- rc->managed_alloc = true;
*dr = rc;
devres_add(dev, dr);
@@ -2042,11 +2042,7 @@ void rc_unregister_device(struct rc_dev *dev)
device_del(&dev->dev);
ida_free(&rc_ida, dev->minor);
-
- if (!dev->managed_alloc)
- rc_free_device(dev);
}
-
EXPORT_SYMBOL_GPL(rc_unregister_device);
/*
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 3b917a2a89188..3f828a564e192 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -1131,11 +1131,13 @@ static void redrat3_dev_disconnect(struct usb_interface *intf)
{
struct usb_device *udev = interface_to_usbdev(intf);
struct redrat3_dev *rr3 = usb_get_intfdata(intf);
+ struct rc_dev *rc = rr3->rc;
usb_set_intfdata(intf, NULL);
- rc_unregister_device(rr3->rc);
+ rc_unregister_device(rc);
led_classdev_unregister(&rr3->led);
redrat3_delete(rr3, udev);
+ rc_free_device(rc);
}
static int redrat3_dev_suspend(struct usb_interface *intf, pm_message_t message)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 6b70bac5f45d6..0ba06bfc9e14b 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -203,6 +203,7 @@ static void st_rc_remove(struct platform_device *pdev)
device_init_wakeup(&pdev->dev, false);
clk_disable_unprepare(rc_dev->sys_clock);
rc_unregister_device(rc_dev->rdev);
+ rc_free_device(rc_dev->rdev);
}
static int st_rc_open(struct rc_dev *rdev)
@@ -334,7 +335,6 @@ static int st_rc_probe(struct platform_device *pdev)
return ret;
rcerr:
rc_unregister_device(rdev);
- rdev = NULL;
clkerr:
clk_disable_unprepare(rc_dev->sys_clock);
err:
diff --git a/drivers/media/rc/streamzap.c b/drivers/media/rc/streamzap.c
index 5a18603f9a95c..7103da57c19f1 100644
--- a/drivers/media/rc/streamzap.c
+++ b/drivers/media/rc/streamzap.c
@@ -388,15 +388,16 @@ static void streamzap_disconnect(struct usb_interface *interface)
struct streamzap_ir *sz = usb_get_intfdata(interface);
struct usb_device *usbdev = interface_to_usbdev(interface);
- usb_set_intfdata(interface, NULL);
-
if (!sz)
return;
- usb_kill_urb(sz->urb_in);
rc_unregister_device(sz->rdev);
+ usb_set_intfdata(interface, NULL);
+
+ usb_kill_urb(sz->urb_in);
usb_free_urb(sz->urb_in);
usb_free_coherent(usbdev, sz->buf_in_len, sz->buf_in, sz->dma_in);
+ rc_free_device(sz->rdev);
kfree(sz);
}
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 92ef4e7c6f69f..cb4c56bf0752a 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -371,6 +371,7 @@ static void sunxi_ir_remove(struct platform_device *pdev)
struct sunxi_ir *ir = platform_get_drvdata(pdev);
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
sunxi_ir_hw_exit(&pdev->dev);
}
diff --git a/drivers/media/rc/ttusbir.c b/drivers/media/rc/ttusbir.c
index 110a469001146..a2a64a860264b 100644
--- a/drivers/media/rc/ttusbir.c
+++ b/drivers/media/rc/ttusbir.c
@@ -333,7 +333,6 @@ static int ttusbir_probe(struct usb_interface *intf,
return 0;
out3:
rc_unregister_device(rc);
- rc = NULL;
out2:
led_classdev_unregister(&tt->led);
out:
@@ -373,6 +372,7 @@ static void ttusbir_disconnect(struct usb_interface *intf)
}
usb_kill_urb(tt->bulk_urb);
usb_free_urb(tt->bulk_urb);
+ rc_free_device(tt->rc);
usb_set_intfdata(intf, NULL);
kfree(tt);
}
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 515469dd82d4c..8e804661a6215 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1132,7 +1132,6 @@ wbcir_probe(struct pnp_dev *device, const struct pnp_device_id *dev_id)
release_region(data->wbase, WAKEUP_IOMEM_LEN);
exit_unregister_device:
rc_unregister_device(data->dev);
- data->dev = NULL;
exit_free_rc:
rc_free_device(data->dev);
exit_unregister_led:
@@ -1163,6 +1162,7 @@ wbcir_remove(struct pnp_dev *device)
wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_EV_EN, 0x00, 0x07);
rc_unregister_device(data->dev);
+ rc_free_device(data->dev);
led_classdev_unregister(&data->led);
diff --git a/drivers/media/rc/xbox_remote.c b/drivers/media/rc/xbox_remote.c
index 3e3da70cf8da0..c64123e9d16a5 100644
--- a/drivers/media/rc/xbox_remote.c
+++ b/drivers/media/rc/xbox_remote.c
@@ -277,14 +277,15 @@ static void xbox_remote_disconnect(struct usb_interface *interface)
struct xbox_remote *xbox_remote;
xbox_remote = usb_get_intfdata(interface);
- usb_set_intfdata(interface, NULL);
if (!xbox_remote) {
dev_warn(&interface->dev, "%s - null device?\n", __func__);
return;
}
- usb_kill_urb(xbox_remote->irq_urb);
rc_unregister_device(xbox_remote->rdev);
+ usb_set_intfdata(interface, NULL);
+ usb_kill_urb(xbox_remote->irq_urb);
+ rc_free_device(xbox_remote->rdev);
usb_free_urb(xbox_remote->irq_urb);
kfree(xbox_remote);
}
diff --git a/drivers/media/usb/au0828/au0828-input.c b/drivers/media/usb/au0828/au0828-input.c
index 7dec1a360da6a..81d0165a3064d 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -357,6 +357,7 @@ void au0828_rc_unregister(struct au0828_dev *dev)
return;
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
/* done */
kfree(ir);
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index 600cff8a4abdc..bd86d250433df 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -187,6 +187,7 @@ static int dvb_usbv2_remote_exit(struct dvb_usb_device *d)
if (d->rc_dev) {
cancel_delayed_work_sync(&d->rc_query_work);
rc_unregister_device(d->rc_dev);
+ rc_free_device(d->rc_dev);
d->rc_dev = NULL;
}
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-remote.c b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
index 65e2c9e2cdc99..6dc11718dfb98 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
@@ -347,10 +347,12 @@ int dvb_usb_remote_exit(struct dvb_usb_device *d)
{
if (d->state & DVB_USB_STATE_REMOTE) {
cancel_delayed_work_sync(&d->rc_query_work);
- if (d->props.rc.mode == DVB_RC_LEGACY)
+ if (d->props.rc.mode == DVB_RC_LEGACY) {
input_unregister_device(d->input_dev);
- else
+ } else {
rc_unregister_device(d->rc_dev);
+ rc_free_device(d->rc_dev);
+ }
}
d->state &= ~DVB_USB_STATE_REMOTE;
return 0;
diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index 20fdd59b55185..ab61d9a29b10e 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -853,6 +853,7 @@ static int em28xx_ir_fini(struct em28xx *dev)
goto ref_put;
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
kfree(ir->i2c_client);
diff --git a/drivers/staging/media/av7110/av7110_ir.c b/drivers/staging/media/av7110/av7110_ir.c
index 68b3979ba5f20..fdae467fd7ab8 100644
--- a/drivers/staging/media/av7110/av7110_ir.c
+++ b/drivers/staging/media/av7110/av7110_ir.c
@@ -151,6 +151,7 @@ int av7110_ir_init(struct av7110 *av7110)
void av7110_ir_exit(struct av7110 *av7110)
{
rc_unregister_device(av7110->ir.rcdev);
+ rc_free_device(av7110->ir.rcdev);
}
//MODULE_AUTHOR("Holger Waechtler <holger@convergence.de>, Oliver Endriss <o.endriss@gmx.de>");
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 35c7a0546f02e..7c964b5ad7926 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -81,7 +81,6 @@ struct lirc_fh {
/**
* struct rc_dev - represents a remote control device
* @dev: driver model's view of this device
- * @managed_alloc: devm_rc_allocate_device was used to create rc_dev
* @registered: set to true by rc_register_device(), false by
* rc_unregister_device
* @idle: used to keep track of RX state
@@ -156,7 +155,6 @@ struct lirc_fh {
*/
struct rc_dev {
struct device dev;
- bool managed_alloc;
bool registered;
bool idle;
bool encode_wakeup;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/2] HID: appletb-kbd: fix UAF and mutex-in-atomic in inactivity timer
From: Aditya Garg @ 2026-04-20 12:47 UTC (permalink / raw)
To: Sangyun Kim, jikos, bentiss; +Cc: qasdev00, linux-input, linux-kernel
In-Reply-To: <20260420051318.1411671-1-sangyun.kim@snu.ac.kr>
On 4/20/26 10:43, Sangyun Kim wrote:
> This series addresses two defects in hid-appletb-kbd's inactivity
> timer subsystem. The two patches target different bugs and are
> logically independent; they are sent together because they touch the
> same tear-down code and because the same maintainer will review both.
>
> Patch 1 fixes a slab use-after-free with two related tear-down windows
> introduced by commit 38224c472a03 ("HID: appletb-kbd: fix slab
> use-after-free bug in appletb_kbd_probe"):
>
> A) Within "if (kbd->backlight_dev)" the order was
> put_device() then timer_delete_sync(). A concurrent
> hid_appletb_bl unbind between those two calls can drop the last
> devm reference and free the backlight_device; the still-armed
> inactivity timer softirq then dereferences the freed object
> through backlight_device_set_brightness() -> mutex_lock(&ops_lock).
>
> B) The "if (kbd->backlight_dev)" block ran before
> hid_hw_close()/hid_hw_stop(), so even after window A is closed a
> late ".event" callback from the HID core (USB URB completion on
> real hardware) can arrive between timer_delete_sync() and
> put_device(), reach reset_inactivity_timer(), re-arm the timer
> via mod_timer(), and reopen the same UAF.
>
> Both windows produce the same KASAN slab-use-after-free on the object
> allocated by devm_backlight_device_register(). Patch 1 closes them
> together by moving hid_hw_close()/hid_hw_stop() before the backlight
> cleanup and, inside that cleanup block, calling timer_delete_sync()
> before put_device(). Shipping both as one commit avoids leaving
> stable kernels in a half-fixed state where only window A is closed.
>
> Patch 2 fixes a separate "sleeping function called from invalid
> context" bug in the same subsystem. The inactivity timer is a
> struct timer_list, so the callback runs in softirq context and calls
> backlight_device_set_brightness() -> mutex_lock() from atomic
> context; reset_inactivity_timer() has the same issue on the
> brightness-restore path (it is called from appletb_kbd_hid_event()
> and appletb_kbd_inp_event(), which run in softirq/IRQ context on
> real USB hardware). Convert the inactivity timer to a delayed_work
> and defer the brightness-restore call to a dedicated work_struct so
> both sleeping calls run in process context.
>
> Sangyun Kim (2):
> HID: appletb-kbd: fix UAF in inactivity-timer cleanup path
> HID: appletb-kbd: run inactivity autodim from workqueues
>
> drivers/hid/hid-appletb-kbd.c | 56 ++++++++++++++++++++++-------------
> 1 file changed, 36 insertions(+), 20 deletions(-)
>
I had a very weird bug just once. And that was when I pressed fn key,
upon releasing, the touchbar mode did not restore to normal.
Although it was just once, and I was never able to reproduce it again.
Have you tested it on your Machine btw?
^ permalink raw reply
* Re: [PATCH v2] iio: magnetometer: hid-sensor-magn-3d: prefer 'unsigned int'
From: Andy Shevchenko @ 2026-04-20 8:42 UTC (permalink / raw)
To: Joshua Crofts
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
linux-input, linux-iio, linux-kernel
In-Reply-To: <20260419180523.37396-1-joshua.crofts1@gmail.com>
On Sun, Apr 19, 2026 at 08:05:23PM +0200, Joshua Crofts wrote:
> Use 'u32' instead of bare 'unsigned' to resolve checkpatch.pl warnings
> and correct type use as defined in the hid_sensor_hub_callbacks struct.
"...in the struct hid_sensor_hub_callbacks."
> No functional change.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/4] HID: pass the buffer size to hid_report_raw_event
From: Benjamin Tissoires @ 2026-04-20 8:01 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Lee Jones, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <938e8afadcbf2d7b9f0397e24926224985d9c385.camel@icenowy.me>
On Apr 20 2026, Icenowy Zheng wrote:
> 在 2026-04-16四的 16:48 +0200，Benjamin Tissoires写道：
> > commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > bogus memset()") enforced the provided data to be at least the size
> > of
> > the declared buffer in the report descriptor to prevent a buffer
> > overflow. However, we can try to be smarter by providing both the
> > buffer
> > size and the data size, meaning that hid_report_raw_event() can make
> > better decision whether we should plaining reject the buffer (buffer
> > overflow attempt) or if we can safely memset it to 0 and pass it to
> > the
> > rest of the stack.
> >
> > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > bogus memset()")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > ---
> > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++++--
> > drivers/hid/hid-core.c | 42 +++++++++++++++++++++++++---
> > ----------
> > drivers/hid/hid-gfrm.c | 4 ++--
> > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > drivers/hid/hid-multitouch.c | 2 +-
> > drivers/hid/hid-primax.c | 2 +-
> > drivers/hid/hid-vivaldi-common.c | 2 +-
> > drivers/hid/wacom_sys.c | 6 +++---
> > drivers/staging/greybus/hid.c | 2 +-
> > include/linux/hid.h | 4 ++--
> > include/linux/hid_bpf.h | 14 ++++++++-----
> > 11 files changed, 53 insertions(+), 33 deletions(-)
>
> ============ 8< ===================
>
> > diff --git a/drivers/staging/greybus/hid.c
> > b/drivers/staging/greybus/hid.c
> > index 1f58c907c036..37e8605c6767 100644
> > --- a/drivers/staging/greybus/hid.c
> > +++ b/drivers/staging/greybus/hid.c
> > @@ -201,7 +201,7 @@ static void gb_hid_init_report(struct gb_hid
> > *ghid, struct hid_report *report)
> > * we just need to setup the input fields, so using
> > * hid_report_raw_event is safe.
> > */
> > - hid_report_raw_event(ghid->hid, report->type, ghid->inbuf,
> > size, 1);
> > + hid_report_raw_event(ghid->hid, report->type, ghid->inbuf,
> > ghib->bufsize, size, 1);
>
> Oops, "ghid" is misspelled here...
Damn, you're correct. Sorry.
Jiri, do you want me to send v3? Or can you fix it while applying?
>
> Found this when building some gaint kernel with this patchset.
Thanks a lot for spotting this.
Cheers,
Benjamin
>
> Thanks,
> Icenowy
>
> > }
> >
> > static void gb_hid_init_reports(struct gb_hid *ghid)
>
^ permalink raw reply
* Re: [PATCH 1/7] iio: HID: Add helper method hid_sensor_adjust_channel_bit_mask()
From: Andy Shevchenko @ 2026-04-20 7:36 UTC (permalink / raw)
To: David Lechner
Cc: Natália Salvino André, andy, bentiss, jic23, jikos,
nuno.sa, srinivas.pandruvada, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <1c49e011-ae23-4c6f-ad6f-f0b494c2dbbc@baylibre.com>
On Sat, Apr 18, 2026 at 11:32:13AM -0500, David Lechner wrote:
> On 4/17/26 5:58 PM, Natália Salvino André wrote:
> > Add helper method to deduplicate code in HID sensors.
...
> > + /* Real storage bits will change based on the report desc. */
> > + channels[channel].scan_type.realbits = size * 8;
>
> There is a BITS_PER_BYTE macro that would make sense here.
> > + /* Maximum size of a sample to capture is u32 */
> > + channels[channel].scan_type.storagebits = sizeof(u32) * 8;
>
> and here.
FWIW, we have BYTES_TO_BITS().
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 2/2] HID: appletb-kbd: run inactivity autodim from workqueues
From: Sangyun Kim @ 2026-04-20 5:13 UTC (permalink / raw)
To: jikos, bentiss; +Cc: qasdev00, gargaditya08, linux-input, linux-kernel, stable
In-Reply-To: <20260420051318.1411671-1-sangyun.kim@snu.ac.kr>
The autodim code in hid-appletb-kbd takes backlight_device->ops_lock
via backlight_device_set_brightness() -> mutex_lock() from two
different atomic contexts:
* appletb_inactivity_timer() is a struct timer_list callback, so it
runs in softirq context. Every expiry triggers
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
Call Trace:
<IRQ>
__might_resched
__mutex_lock
backlight_device_set_brightness
appletb_inactivity_timer
call_timer_fn
run_timer_softirq
* reset_inactivity_timer() is called from appletb_kbd_hid_event() and
appletb_kbd_inp_event(). On real USB hardware these run in
softirq/IRQ context (URB completion and input-event dispatch).
When the Touch Bar has already been dimmed or turned off, the
reset path calls backlight_device_set_brightness() directly to
restore brightness, producing the same warning.
Both call sites hit the same mutex_lock()-from-atomic bug. Fix them
together by moving the blocking work onto the system workqueue:
* Convert the inactivity timer from struct timer_list to
struct delayed_work; the callback (appletb_inactivity_work) now
runs in process context where mutex_lock() is legal.
* Add a dedicated struct work_struct restore_brightness_work and have
reset_inactivity_timer() schedule it instead of calling
backlight_device_set_brightness() directly.
Cancel both works synchronously during driver tear-down alongside the
existing backlight reference drop.
The semantics are unchanged (same delays, same state transitions on
dim, turn-off and user activity); only the execution context of the
sleeping call changes. The timer field and callback are renamed to
match their new type; reset_inactivity_timer() keeps its name because
it is invoked from input event paths that read naturally as "reset
the inactivity timer".
Fixes: 93a0fc489481 ("HID: hid-appletb-kbd: add support for automatic brightness control while using the touchbar")
Cc: stable@vger.kernel.org
Signed-off-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
---
drivers/hid/hid-appletb-kbd.c | 44 ++++++++++++++++++++++++-----------
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/hid-appletb-kbd.c b/drivers/hid/hid-appletb-kbd.c
index 8feac9e3589b..462010a75899 100644
--- a/drivers/hid/hid-appletb-kbd.c
+++ b/drivers/hid/hid-appletb-kbd.c
@@ -17,7 +17,7 @@
#include <linux/module.h>
#include <linux/string.h>
#include <linux/backlight.h>
-#include <linux/timer.h>
+#include <linux/workqueue.h>
#include <linux/input/sparse-keymap.h>
#include "hid-ids.h"
@@ -62,7 +62,8 @@ struct appletb_kbd {
struct input_handle kbd_handle;
struct input_handle tpd_handle;
struct backlight_device *backlight_dev;
- struct timer_list inactivity_timer;
+ struct delayed_work inactivity_work;
+ struct work_struct restore_brightness_work;
bool has_dimmed;
bool has_turned_off;
u8 saved_mode;
@@ -164,16 +165,18 @@ static int appletb_tb_key_to_slot(unsigned int code)
}
}
-static void appletb_inactivity_timer(struct timer_list *t)
+static void appletb_inactivity_work(struct work_struct *work)
{
- struct appletb_kbd *kbd = timer_container_of(kbd, t, inactivity_timer);
+ struct appletb_kbd *kbd = container_of(to_delayed_work(work),
+ struct appletb_kbd,
+ inactivity_work);
if (kbd->backlight_dev && appletb_tb_autodim) {
if (!kbd->has_dimmed) {
backlight_device_set_brightness(kbd->backlight_dev, 1);
kbd->has_dimmed = true;
- mod_timer(&kbd->inactivity_timer,
- jiffies + secs_to_jiffies(appletb_tb_idle_timeout));
+ mod_delayed_work(system_wq, &kbd->inactivity_work,
+ secs_to_jiffies(appletb_tb_idle_timeout));
} else if (!kbd->has_turned_off) {
backlight_device_set_brightness(kbd->backlight_dev, 0);
kbd->has_turned_off = true;
@@ -181,16 +184,25 @@ static void appletb_inactivity_timer(struct timer_list *t)
}
}
+static void appletb_restore_brightness_work(struct work_struct *work)
+{
+ struct appletb_kbd *kbd = container_of(work, struct appletb_kbd,
+ restore_brightness_work);
+
+ if (kbd->backlight_dev)
+ backlight_device_set_brightness(kbd->backlight_dev, 2);
+}
+
static void reset_inactivity_timer(struct appletb_kbd *kbd)
{
if (kbd->backlight_dev && appletb_tb_autodim) {
if (kbd->has_dimmed || kbd->has_turned_off) {
- backlight_device_set_brightness(kbd->backlight_dev, 2);
kbd->has_dimmed = false;
kbd->has_turned_off = false;
+ schedule_work(&kbd->restore_brightness_work);
}
- mod_timer(&kbd->inactivity_timer,
- jiffies + secs_to_jiffies(appletb_tb_dim_timeout));
+ mod_delayed_work(system_wq, &kbd->inactivity_work,
+ secs_to_jiffies(appletb_tb_dim_timeout));
}
}
@@ -408,9 +420,11 @@ static int appletb_kbd_probe(struct hid_device *hdev, const struct hid_device_id
dev_err_probe(dev, -ENODEV, "Failed to get backlight device\n");
} else {
backlight_device_set_brightness(kbd->backlight_dev, 2);
- timer_setup(&kbd->inactivity_timer, appletb_inactivity_timer, 0);
- mod_timer(&kbd->inactivity_timer,
- jiffies + secs_to_jiffies(appletb_tb_dim_timeout));
+ INIT_DELAYED_WORK(&kbd->inactivity_work, appletb_inactivity_work);
+ INIT_WORK(&kbd->restore_brightness_work,
+ appletb_restore_brightness_work);
+ mod_delayed_work(system_wq, &kbd->inactivity_work,
+ secs_to_jiffies(appletb_tb_dim_timeout));
}
kbd->inp_handler.event = appletb_kbd_inp_event;
@@ -444,7 +458,8 @@ static int appletb_kbd_probe(struct hid_device *hdev, const struct hid_device_id
stop_hw:
hid_hw_stop(hdev);
if (kbd->backlight_dev) {
- timer_delete_sync(&kbd->inactivity_timer);
+ cancel_delayed_work_sync(&kbd->inactivity_work);
+ cancel_work_sync(&kbd->restore_brightness_work);
put_device(&kbd->backlight_dev->dev);
}
return ret;
@@ -461,7 +476,8 @@ static void appletb_kbd_remove(struct hid_device *hdev)
hid_hw_stop(hdev);
if (kbd->backlight_dev) {
- timer_delete_sync(&kbd->inactivity_timer);
+ cancel_delayed_work_sync(&kbd->inactivity_work);
+ cancel_work_sync(&kbd->restore_brightness_work);
put_device(&kbd->backlight_dev->dev);
}
}
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] HID: appletb-kbd: fix UAF in inactivity-timer cleanup path
From: Sangyun Kim @ 2026-04-20 5:13 UTC (permalink / raw)
To: jikos, bentiss; +Cc: qasdev00, gargaditya08, linux-input, linux-kernel, stable
In-Reply-To: <20260420051318.1411671-1-sangyun.kim@snu.ac.kr>
Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in
appletb_kbd_probe") added timer_delete_sync(&kbd->inactivity_timer) to
both the probe close_hw error path and appletb_kbd_remove(), but the
way it was wired in left the inactivity timer reachable during driver
tear-down via two distinct windows.
Window A -- put_device() before timer_delete_sync():
put_device(&kbd->backlight_dev->dev);
timer_delete_sync(&kbd->inactivity_timer);
The inactivity_timer softirq reads kbd->backlight_dev and calls
backlight_device_set_brightness() -> mutex_lock(&ops_lock). If a
concurrent hid_appletb_bl unbind drops the last devm reference
between these two calls, the backlight_device is freed and the
mutex_lock() touches freed memory.
Window B -- backlight cleanup before hid_hw_stop():
if (kbd->backlight_dev) {
timer_delete_sync(...);
put_device(...);
}
hid_hw_close(hdev);
hid_hw_stop(hdev);
Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run
afterwards, so a late ".event" callback from the HID core (USB URB
completion on real Apple hardware) can arrive after
timer_delete_sync() drained the softirq but before put_device() drops
the reference. That callback reaches reset_inactivity_timer(), which
calls mod_timer() and re-arms the timer. The freshly re-armed timer
can then fire on the about-to-be-freed backlight_device.
Both windows produce the same KASAN slab-use-after-free:
BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0
Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0
Call Trace:
<IRQ>
__mutex_lock
backlight_device_set_brightness
appletb_inactivity_timer
call_timer_fn
run_timer_softirq
handle_softirqs
Allocated by task N:
devm_backlight_device_register
appletb_bl_probe
Freed by task M:
(concurrent hid_appletb_bl unbind path)
Close both windows at once by reworking the tear-down in
appletb_kbd_remove() and in the probe close_hw error path so that
1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup,
guaranteeing no further .event callback can fire and re-arm the
timer, and
2) inside the "if (kbd->backlight_dev)" block, timer_delete_sync()
runs before put_device(), so the softirq is drained before the
final reference is dropped.
Fixes: 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe")
Cc: stable@vger.kernel.org
Signed-off-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
---
drivers/hid/hid-appletb-kbd.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/hid-appletb-kbd.c b/drivers/hid/hid-appletb-kbd.c
index 0fdc0968b9ef..8feac9e3589b 100644
--- a/drivers/hid/hid-appletb-kbd.c
+++ b/drivers/hid/hid-appletb-kbd.c
@@ -440,13 +440,13 @@ static int appletb_kbd_probe(struct hid_device *hdev, const struct hid_device_id
unregister_handler:
input_unregister_handler(&kbd->inp_handler);
close_hw:
- if (kbd->backlight_dev) {
- put_device(&kbd->backlight_dev->dev);
- timer_delete_sync(&kbd->inactivity_timer);
- }
hid_hw_close(hdev);
stop_hw:
hid_hw_stop(hdev);
+ if (kbd->backlight_dev) {
+ timer_delete_sync(&kbd->inactivity_timer);
+ put_device(&kbd->backlight_dev->dev);
+ }
return ret;
}
@@ -457,13 +457,13 @@ static void appletb_kbd_remove(struct hid_device *hdev)
appletb_kbd_set_mode(kbd, APPLETB_KBD_MODE_OFF);
input_unregister_handler(&kbd->inp_handler);
+ hid_hw_close(hdev);
+ hid_hw_stop(hdev);
+
if (kbd->backlight_dev) {
- put_device(&kbd->backlight_dev->dev);
timer_delete_sync(&kbd->inactivity_timer);
+ put_device(&kbd->backlight_dev->dev);
}
-
- hid_hw_close(hdev);
- hid_hw_stop(hdev);
}
static int appletb_kbd_suspend(struct hid_device *hdev, pm_message_t msg)
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] HID: appletb-kbd: fix UAF and mutex-in-atomic in inactivity timer
From: Sangyun Kim @ 2026-04-20 5:13 UTC (permalink / raw)
To: jikos, bentiss; +Cc: qasdev00, gargaditya08, linux-input, linux-kernel
This series addresses two defects in hid-appletb-kbd's inactivity
timer subsystem. The two patches target different bugs and are
logically independent; they are sent together because they touch the
same tear-down code and because the same maintainer will review both.
Patch 1 fixes a slab use-after-free with two related tear-down windows
introduced by commit 38224c472a03 ("HID: appletb-kbd: fix slab
use-after-free bug in appletb_kbd_probe"):
A) Within "if (kbd->backlight_dev)" the order was
put_device() then timer_delete_sync(). A concurrent
hid_appletb_bl unbind between those two calls can drop the last
devm reference and free the backlight_device; the still-armed
inactivity timer softirq then dereferences the freed object
through backlight_device_set_brightness() -> mutex_lock(&ops_lock).
B) The "if (kbd->backlight_dev)" block ran before
hid_hw_close()/hid_hw_stop(), so even after window A is closed a
late ".event" callback from the HID core (USB URB completion on
real hardware) can arrive between timer_delete_sync() and
put_device(), reach reset_inactivity_timer(), re-arm the timer
via mod_timer(), and reopen the same UAF.
Both windows produce the same KASAN slab-use-after-free on the object
allocated by devm_backlight_device_register(). Patch 1 closes them
together by moving hid_hw_close()/hid_hw_stop() before the backlight
cleanup and, inside that cleanup block, calling timer_delete_sync()
before put_device(). Shipping both as one commit avoids leaving
stable kernels in a half-fixed state where only window A is closed.
Patch 2 fixes a separate "sleeping function called from invalid
context" bug in the same subsystem. The inactivity timer is a
struct timer_list, so the callback runs in softirq context and calls
backlight_device_set_brightness() -> mutex_lock() from atomic
context; reset_inactivity_timer() has the same issue on the
brightness-restore path (it is called from appletb_kbd_hid_event()
and appletb_kbd_inp_event(), which run in softirq/IRQ context on
real USB hardware). Convert the inactivity timer to a delayed_work
and defer the brightness-restore call to a dedicated work_struct so
both sleeping calls run in process context.
Sangyun Kim (2):
HID: appletb-kbd: fix UAF in inactivity-timer cleanup path
HID: appletb-kbd: run inactivity autodim from workqueues
drivers/hid/hid-appletb-kbd.c | 56 ++++++++++++++++++++++-------------
1 file changed, 36 insertions(+), 20 deletions(-)
--
2.34.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox