All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Haoxiang Li" <haoxiang_li2024@163.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH v3 1/2] HID: sensor: custom: Fix use-after-free in enable_sensor
Date: Tue, 07 Jul 2026 07:50:34 +0000	[thread overview]
Message-ID: <20260707075035.108241F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260707071545.3087073-2-haoxiang_li2024@163.com>

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

Pre-existing issues:
- [Critical] Incorrect mapping between the sysfs attribute name index and the `sensor_inst->fields` array leads to Heap Out-Of-Bounds reads.
- [High] The `/dev/HID-SENSOR-*` character device operations do not synchronize with device removal, leading to Use-After-Free on `devm`-managed structures.
- [High] The `data_fifo` is freed before the sensor hub interrupt callback is unregistered during device removal, creating a race condition that leads to a Use-After-Free.
- [High] The sensor hub device is never closed on driver removal if it was concurrently enabled, causing a permanent power and reference count leak.
--

--- Patch [1]: [PATCH v3 1/2] HID: sensor: custom: Fix use-after-free in enable_sensor ---
commit d433ad359db5f5f5744d4b3f8a4dc8088af760b6
Author: Haoxiang Li <haoxiang_li2024@163.com>

HID: sensor: custom: Fix use-after-free in enable_sensor

This commit fixes a use-after-free by altering the initialization and cleanup
order of the sysfs attributes and the enable_sensor group. This prevents
enable_sensor from being accessed before its dependencies are fully
initialized or after they have been freed.

Link: https://sashiko.dev/#/patchset/20260623021950.1736413-1-haoxiang_li2024@163.com?part=1

> diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
> index afffea8940214..6b0da2e0e1c93 100644
> --- a/drivers/hid/hid-sensor-custom.c
> +++ b/drivers/hid/hid-sensor-custom.c
> @@ -1005,26 +1005,26 @@ static int hid_sensor_custom_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> -	ret = sysfs_create_group(&sensor_inst->pdev->dev.kobj,
> -				 &enable_sensor_attr_group);
> +	ret = hid_sensor_custom_add_attributes(sensor_inst);

[Severity: Critical]
This is a pre-existing issue, but is there an out-of-bounds read when parsing
the sysfs strings created by this function?

During initialization, if a HID field is skipped, it is not appended to the
sensor_inst->fields array, keeping sensor_field_count small. However, its
original field index is embedded into the sysfs file name.

When a valid sysfs file is later read, show_value() parses the index from
the filename and uses it directly as an array index:

    if (sscanf(attr->attr.name, "input-%x-%x-%s",
               &index, &usage, name) == 3) {
        input = true;
        field_index = index;
    }
    ...
    value = sensor_inst->fields[field_index].attribute.logical_minimum;

Could this bypass the array bounds and leak memory to userspace?

[ ... ]

> @@ -1042,9 +1042,10 @@ static void hid_sensor_custom_remove(struct platform_device *pdev)
>  	}
>  
>  	hid_sensor_custom_dev_if_remove(sensor_inst);

[Severity: High]
This isn't a bug introduced by this patch, but doesn't this leave a
use-after-free window?

If a user holds open the misc device /dev/HID-SENSOR-*, misc_deregister()
does not close existing open file descriptors. Since sensor_inst is
allocated with devm_kzalloc(), it is freed when remove() returns.

Would subsequent calls to hid_sensor_custom_read(), poll(), or
hid_sensor_custom_release() dereference the freed sensor_inst object?

[Severity: High]
This is a pre-existing issue, but is there a race condition here?

The data_fifo is freed by hid_sensor_custom_dev_if_remove() before the
interrupt callback is unregistered by sensor_hub_remove_callback().

If an interrupt occurs while sysfs_remove_group() or
hid_sensor_custom_remove_attributes() is blocking, couldn't the callback
hid_sensor_capture_sample() write incoming data to the freed data_fifo
via kfifo_in()?

[Severity: High]
This is also a pre-existing issue, but does this function leak the sensor hub
reference and power state?

If a user writes '1' to the enable_sensor sysfs attribute,
sensor_hub_device_open() powers on the device and takes a reference. Since
this function tears down the interfaces without checking sensor_inst->enable
and calling sensor_hub_device_close(), does the HID device reference leak
permanently?

> -	hid_sensor_custom_remove_attributes(sensor_inst);
> +	/* Remove enable_sensor first as it uses fields via power_state/report_state. */
>  	sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
>  			   &enable_sensor_attr_group);
> +	hid_sensor_custom_remove_attributes(sensor_inst);
>  	sensor_hub_remove_callback(hsdev, hsdev->usage);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707071545.3087073-1-haoxiang_li2024@163.com?part=1

  reply	other threads:[~2026-07-07  7:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07  7:15 [PATCH v3 0/2] HID: sensor: custom: Fix fields lifetime issues Haoxiang Li
2026-07-07  7:15 ` [PATCH v3 1/2] HID: sensor: custom: Fix use-after-free in enable_sensor Haoxiang Li
2026-07-07  7:50   ` sashiko-bot [this message]
2026-07-08 17:58   ` srinivas pandruvada
2026-07-07  7:15 ` [PATCH v3 2/2] HID: sensor: custom: Fix field sysfs group cleanup on failure Haoxiang Li
2026-07-07  8:04   ` sashiko-bot
2026-07-08 17:58   ` srinivas pandruvada
2026-07-11 23:59 ` [PATCH v3 0/2] HID: sensor: custom: Fix fields lifetime issues Jonathan Cameron

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20260707075035.108241F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=haoxiang_li2024@163.com \
    --cc=linux-input@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

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

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