[v1] HID: sensor-hub: Fail unfinished multi-value reads on removal

[PATCH v1] HID: sensor-hub: Fail unfinished multi-value reads on removal

Posted by Yibo Tan 2 weeks ago

sensor_hub_remove() completes pending reads after stopping the HID device,
but does not record why they completed.  A successful completion wait
therefore returns zero even if no complete input report was received.
Multi-value IIO callers then format their untouched automatic buffer as a
successful result.

With a valid four-element signed 32-bit quaternion report descriptor, an
unprivileged reader received all 16 bytes of the untouched buffer.  Across
11 independent KASLR-enabled boots, four reads exposed exact pointers to
dev_rot_channels or dev_sysfs_ops.  Subtracting the matching link-time
symbol address recovered the kernel KASLR slide in all four cases.

The reader ran as UID/GID 65534 with no effective capabilities through the
mode-0644 IIO attribute.  The test used a privileged UHID broker to create
and remove the provider; it does not demonstrate unprivileged provider
removal.

Publish -ENODEV through pending.raw_size before completing an unfinished
multi-value request, and propagate the error after a successful wait.  A
fully received response already has a positive raw_size and remains
successful; max_raw_size is zero for the separate single-value path.

The Root B-only repair returned -ENODEV with no payload or kernel
diagnostic in 3/3 matching signed-32-bit runs.

A source reproducer, complete vulnerable and fixed serial logs, result
tables, and checksums are available at:

https://github.com/kimaiden1984-boop/linux-kernel-poc-collections/tree/main/cases/hid-sensor-quaternion-root-b-kaslr

Fixes: f784fcea4506 ("HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>
---
 drivers/hid/hid-sensor-hub.c   | 7 ++++++-
 include/linux/hid-sensor-hub.h | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 6470a290ebfc..687f8defa2f0 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -334,6 +334,8 @@ int sensor_hub_input_attr_read_values(struct hid_sensor_hub_device *hsdev,
 			ret = -ETIMEDOUT;
 		else if (cycles < 0)
 			ret = cycles;
+		else if (hsdev->pending.raw_size < 0)
+			ret = hsdev->pending.raw_size;
 
 		hsdev->pending.status = false;
 	}
@@ -805,8 +807,11 @@ static int sensor_hub_finalize_pending_fn(struct device *dev, void *data)
 {
 	struct hid_sensor_hub_device *hsdev = dev->platform_data;
 
-	if (hsdev->pending.status)
+	if (hsdev->pending.status) {
+		if (hsdev->pending.max_raw_size && !hsdev->pending.raw_size)
+			hsdev->pending.raw_size = -ENODEV;
 		complete(&hsdev->pending.ready);
+	}
 
 	return 0;
 }
diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-sensor-hub.h
index ab5cc8db3fbb..4ad53304bb0b 100644
--- a/include/linux/hid-sensor-hub.h
+++ b/include/linux/hid-sensor-hub.h
@@ -41,7 +41,7 @@ struct hid_sensor_hub_attribute_info {
  * @ready:		Completion synchronization data.
  * @usage_id:		Usage id for physical device, e.g. gyro usage id.
  * @attr_usage_id:	Usage Id of a field, e.g. X-axis for a gyro.
- * @raw_size:		Response size for a read request.
+ * @raw_size:		Response size or negative error for a read request.
  * @raw_data:		Place holder for received response.
  * @index:		Current write index into raw_data for multi-byte reads.
  * @max_raw_size:	Total buffer size for multi-byte reads; 0 for single-value reads.
-- 
2.39.5

Re: [PATCH v1] HID: sensor-hub: Fail unfinished multi-value reads on removal

Posted by Andy Shevchenko 2 weeks ago

On Fri, Sep 11, 2026 at 05:20:39PM +0800, Yibo Tan wrote:
> sensor_hub_remove() completes pending reads after stopping the HID device,
> but does not record why they completed.  A successful completion wait
> therefore returns zero even if no complete input report was received.
> Multi-value IIO callers then format their untouched automatic buffer as a
> successful result.
> 
> With a valid four-element signed 32-bit quaternion report descriptor, an
> unprivileged reader received all 16 bytes of the untouched buffer.  Across
> 11 independent KASLR-enabled boots, four reads exposed exact pointers to
> dev_rot_channels or dev_sysfs_ops.  Subtracting the matching link-time
> symbol address recovered the kernel KASLR slide in all four cases.
> 
> The reader ran as UID/GID 65534 with no effective capabilities through the
> mode-0644 IIO attribute.  The test used a privileged UHID broker to create
> and remove the provider; it does not demonstrate unprivileged provider
> removal.
> 
> Publish -ENODEV through pending.raw_size before completing an unfinished
> multi-value request, and propagate the error after a successful wait.  A
> fully received response already has a positive raw_size and remains
> successful; max_raw_size is zero for the separate single-value path.
> 
> The Root B-only repair returned -ENODEV with no payload or kernel
> diagnostic in 3/3 matching signed-32-bit runs.
> 
> A source reproducer, complete vulnerable and fixed serial logs, result
> tables, and checksums are available at:

> https://github.com/kimaiden1984-boop/linux-kernel-poc-collections/tree/main/cases/hid-sensor-quaternion-root-b-kaslr

Make it a Link tag and add reference to the text.

> Fixes: f784fcea4506 ("HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:GPT-5

Assisted-by: LLM

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2] HID: sensor-hub: Fail unfinished multi-value reads on removal

Posted by Yibo Tan 1 week, 6 days ago

sensor_hub_remove() completes pending reads after stopping the HID device,
but does not record why they completed.  A successful completion wait
therefore returns zero even if no complete input report was received.
Multi-value IIO callers then format their untouched automatic buffer as a
successful result.

With a valid four-element signed 32-bit quaternion report descriptor, an
unprivileged reader received all 16 bytes of the untouched buffer.  Across
11 independent KASLR-enabled boots, four reads exposed exact pointers to
dev_rot_channels or dev_sysfs_ops.  Subtracting the matching link-time
symbol address recovered the kernel KASLR slide in all four cases.

The reader ran as UID/GID 65534 with no effective capabilities through the
mode-0644 IIO attribute.  The test used a privileged UHID broker to create
and remove the provider; it does not demonstrate unprivileged provider
removal.

Publish -ENODEV through pending.raw_size before completing an unfinished
multi-value request, and propagate the error after a successful wait.  A
fully received response already has a positive raw_size and remains
successful; max_raw_size is zero for the separate single-value path.

The Root B-only repair returned -ENODEV with no payload or kernel
diagnostic in 3/3 matching signed-32-bit runs.  The source reproducer,
complete vulnerable and fixed serial logs, result tables, and checksums are
available in [1].

Link: https://github.com/kimaiden1984-boop/linux-kernel-poc-collections/tree/main/cases/hid-sensor-quaternion-root-b-kaslr [1]
Fixes: f784fcea4506 ("HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>
---
Changes in v2:
- Turn the reproducer URL into a Link trailer and cite it from the text.
- Use the reviewer-requested generic LLM assistance trailer.

v1: https://lore.kernel.org/r/20260911092039.234253-1-lhfff@tju.edu.cn/

 drivers/hid/hid-sensor-hub.c   | 7 ++++++-
 include/linux/hid-sensor-hub.h | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 6470a290ebfc..687f8defa2f0 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -334,6 +334,8 @@ int sensor_hub_input_attr_read_values(struct hid_sensor_hub_device *hsdev,
 			ret = -ETIMEDOUT;
 		else if (cycles < 0)
 			ret = cycles;
+		else if (hsdev->pending.raw_size < 0)
+			ret = hsdev->pending.raw_size;
 
 		hsdev->pending.status = false;
 	}
@@ -805,8 +807,11 @@ static int sensor_hub_finalize_pending_fn(struct device *dev, void *data)
 {
 	struct hid_sensor_hub_device *hsdev = dev->platform_data;
 
-	if (hsdev->pending.status)
+	if (hsdev->pending.status) {
+		if (hsdev->pending.max_raw_size && !hsdev->pending.raw_size)
+			hsdev->pending.raw_size = -ENODEV;
 		complete(&hsdev->pending.ready);
+	}
 
 	return 0;
 }
diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-sensor-hub.h
index ab5cc8db3fbb..4ad53304bb0b 100644
--- a/include/linux/hid-sensor-hub.h
+++ b/include/linux/hid-sensor-hub.h
@@ -41,7 +41,7 @@ struct hid_sensor_hub_attribute_info {
  * @ready:		Completion synchronization data.
  * @usage_id:		Usage id for physical device, e.g. gyro usage id.
  * @attr_usage_id:	Usage Id of a field, e.g. X-axis for a gyro.
- * @raw_size:		Response size for a read request.
+ * @raw_size:		Response size or negative error for a read request.
  * @raw_data:		Place holder for received response.
  * @index:		Current write index into raw_data for multi-byte reads.
  * @max_raw_size:	Total buffer size for multi-byte reads; 0 for single-value reads.
-- 
2.39.5

Re: [PATCH v2] HID: sensor-hub: Fail unfinished multi-value reads on remo

Posted by Jonathan Cameron 1 week, 5 days ago

On Sat, 12 Sep 2026 13:02:57 +0800
Yibo Tan <lhfff@tju.edu.cn> wrote:

> sensor_hub_remove() completes pending reads after stopping the HID device,
> but does not record why they completed.  A successful completion wait
> therefore returns zero even if no complete input report was received.
> Multi-value IIO callers then format their untouched automatic buffer as a
> successful result.
> 
> With a valid four-element signed 32-bit quaternion report descriptor, an
> unprivileged reader received all 16 bytes of the untouched buffer.  Across
> 11 independent KASLR-enabled boots, four reads exposed exact pointers to
> dev_rot_channels or dev_sysfs_ops.  Subtracting the matching link-time
> symbol address recovered the kernel KASLR slide in all four cases.
> 
> The reader ran as UID/GID 65534 with no effective capabilities through the
> mode-0644 IIO attribute.  The test used a privileged UHID broker to create
> and remove the provider; it does not demonstrate unprivileged provider
> removal.
> 
> Publish -ENODEV through pending.raw_size before completing an unfinished
> multi-value request, and propagate the error after a successful wait.  A
> fully received response already has a positive raw_size and remains
> successful; max_raw_size is zero for the separate single-value path.
> 
> The Root B-only repair returned -ENODEV with no payload or kernel
> diagnostic in 3/3 matching signed-32-bit runs.  The source reproducer,
> complete vulnerable and fixed serial logs, result tables, and checksums are
> available in [1].
> 
> Link: https://github.com/kimaiden1984-boop/linux-kernel-poc-collections/tree/main/cases/hid-sensor-quaternion-root-b-kaslr [1]
> Fixes: f784fcea4506 ("HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>

Thanks for the report and fix. Looks good to me, but I'm a little
concerned about fragility of relying on ordering of data being set
and the update of raw_size (in sensorhub_raw_event()). It is messy 
for a compiler to reorder it but I think is allowed to in theory
at least.

Perhaps it is safer for these tear down paths to just set a flag before
the shutdown extra completion and ensure an error is returned in
anything that is waiting on that completion if that flag is set?
That flag would be before the new competion so I think ordering
would be fine.  Might result in extra errors to userspace but we don't
really care when ripping things down.

Jonathan


> ---
> Changes in v2:
> - Turn the reproducer URL into a Link trailer and cite it from the text.
> - Use the reviewer-requested generic LLM assistance trailer.
> 
> v1: https://lore.kernel.org/r/20260911092039.234253-1-lhfff@tju.edu.cn/
> 
>  drivers/hid/hid-sensor-hub.c   | 7 ++++++-
>  include/linux/hid-sensor-hub.h | 2 +-
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index 6470a290ebfc..687f8defa2f0 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -334,6 +334,8 @@ int sensor_hub_input_attr_read_values(struct hid_sensor_hub_device *hsdev,
>  			ret = -ETIMEDOUT;
>  		else if (cycles < 0)
>  			ret = cycles;
> +		else if (hsdev->pending.raw_size < 0)
> +			ret = hsdev->pending.raw_size;
>  
>  		hsdev->pending.status = false;
>  	}
> @@ -805,8 +807,11 @@ static int sensor_hub_finalize_pending_fn(struct device *dev, void *data)
>  {
>  	struct hid_sensor_hub_device *hsdev = dev->platform_data;
>  
> -	if (hsdev->pending.status)
> +	if (hsdev->pending.status) {
> +		if (hsdev->pending.max_raw_size && !hsdev->pending.raw_size)
> +			hsdev->pending.raw_size = -ENODEV;
>  		complete(&hsdev->pending.ready);
> +	}
>  
>  	return 0;
>  }
> diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-sensor-hub.h
> index ab5cc8db3fbb..4ad53304bb0b 100644
> --- a/include/linux/hid-sensor-hub.h
> +++ b/include/linux/hid-sensor-hub.h
> @@ -41,7 +41,7 @@ struct hid_sensor_hub_attribute_info {
>   * @ready:		Completion synchronization data.
>   * @usage_id:		Usage id for physical device, e.g. gyro usage id.
>   * @attr_usage_id:	Usage Id of a field, e.g. X-axis for a gyro.
> - * @raw_size:		Response size for a read request.
> + * @raw_size:		Response size or negative error for a read request.
>   * @raw_data:		Place holder for received response.
>   * @index:		Current write index into raw_data for multi-byte reads.
>   * @max_raw_size:	Total buffer size for multi-byte reads; 0 for single-value reads.

[PATCH v3] HID: sensor-hub: Fail unfinished multi-value reads on removal

Posted by Yibo Tan 1 week, 5 days ago

sensor_hub_remove() completes pending reads after stopping the HID device,
but does not record why they completed.  A successful completion wait
therefore returns zero even if no complete input report was received.
Multi-value IIO callers then format their untouched automatic buffer as a
successful result.

With a valid four-element signed 32-bit quaternion report descriptor, an
unprivileged reader received all 16 bytes of the untouched buffer.  Across
11 independent KASLR-enabled boots, four reads exposed exact pointers to
dev_rot_channels or dev_sysfs_ops.  Subtracting the matching link-time
symbol address recovered the kernel KASLR slide in all four cases.

The reader ran as UID/GID 65534 with no effective capabilities through the
mode-0644 IIO attribute.  The test used a privileged UHID broker to create
and remove the provider; it does not demonstrate unprivileged provider
removal.

Mark a pending request as shut down before completing it from the removal
path, and return -ENODEV from a multi-value read that observes the marker
after a successful wait.  Let removal win even if a response raced with
teardown, since the device is no longer available.

The Root B-only repair returned -ENODEV with no payload or kernel
diagnostic in 3/3 matching signed-32-bit runs.  The source reproducer,
complete vulnerable and fixed serial logs, result tables, and checksums are
available in [1].

Link: https://github.com/kimaiden1984-boop/linux-kernel-poc-collections/tree/main/cases/hid-sensor-quaternion-root-b-kaslr [1]
Fixes: f784fcea4506 ("HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads")
Cc: stable@vger.kernel.org
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Assisted-by: LLM
Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>
---
Changes in v3:
- Replace the raw_size error sentinel with a dedicated teardown flag, as
  suggested by Jonathan Cameron.
- Let teardown win if it races with a completed response.

v2: https://lore.kernel.org/r/20260912050257.837340-1-lhfff@tju.edu.cn/

 drivers/hid/hid-sensor-hub.c   | 6 +++++-
 include/linux/hid-sensor-hub.h | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 6470a290ebfc..a9bd72218c07 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -334,6 +334,8 @@ int sensor_hub_input_attr_read_values(struct hid_sensor_hub_device *hsdev,
 			ret = -ETIMEDOUT;
 		else if (cycles < 0)
 			ret = cycles;
+		else if (hsdev->pending.shutdown)
+			ret = -ENODEV;
 
 		hsdev->pending.status = false;
 	}
@@ -805,8 +807,10 @@ static int sensor_hub_finalize_pending_fn(struct device *dev, void *data)
 {
 	struct hid_sensor_hub_device *hsdev = dev->platform_data;
 
-	if (hsdev->pending.status)
+	if (hsdev->pending.status) {
+		hsdev->pending.shutdown = true;
 		complete(&hsdev->pending.ready);
+	}
 
 	return 0;
 }
diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-sensor-hub.h
index ab5cc8db3fbb..5aecf4474183 100644
--- a/include/linux/hid-sensor-hub.h
+++ b/include/linux/hid-sensor-hub.h
@@ -38,6 +38,7 @@ struct hid_sensor_hub_attribute_info {
 /**
  * struct sensor_hub_pending - Synchronous read pending information
  * @status:		Pending status true/false.
+ * @shutdown:		The device is being removed.
  * @ready:		Completion synchronization data.
  * @usage_id:		Usage id for physical device, e.g. gyro usage id.
  * @attr_usage_id:	Usage Id of a field, e.g. X-axis for a gyro.
@@ -48,6 +49,7 @@ struct hid_sensor_hub_attribute_info {
  */
 struct sensor_hub_pending {
 	bool status;
+	bool shutdown;
 	struct completion ready;
 	u32 usage_id;
 	u32 attr_usage_id;
-- 
2.39.5

Re: [PATCH v3] HID: sensor-hub: Fail unfinished multi-value reads on removal

Posted by srinivas pandruvada 1 week, 4 days ago

On Sun, 2026-09-13 at 15:29 +0800, Yibo Tan wrote:
> sensor_hub_remove() completes pending reads after stopping the HID
> device,
> but does not record why they completed.  A successful completion wait
> therefore returns zero even if no complete input report was received.
> Multi-value IIO callers then format their untouched automatic buffer
> as a
> successful result.
> 
> With a valid four-element signed 32-bit quaternion report descriptor,
> an
> unprivileged reader received all 16 bytes of the untouched buffer. 
> Across
> 11 independent KASLR-enabled boots, four reads exposed exact pointers
> to
> dev_rot_channels or dev_sysfs_ops.  Subtracting the matching link-
> time
> symbol address recovered the kernel KASLR slide in all four cases.
> 
> The reader ran as UID/GID 65534 with no effective capabilities
> through the
> mode-0644 IIO attribute.  The test used a privileged UHID broker to
> create
> and remove the provider; it does not demonstrate unprivileged
> provider
> removal.
> 
> Mark a pending request as shut down before completing it from the
> removal
> path, and return -ENODEV from a multi-value read that observes the
> marker
> after a successful wait.  Let removal win even if a response raced
> with
> teardown, since the device is no longer available.
> 
> The Root B-only repair returned -ENODEV with no payload or kernel
> diagnostic in 3/3 matching signed-32-bit runs.  The source
> reproducer,
> complete vulnerable and fixed serial logs, result tables, and
> checksums are
> available in [1].
> 
> Link:
> https://github.com/kimaiden1984-boop/linux-kernel-poc-collections/tree/main/cases/hid-sensor-quaternion-root-b-kaslr
>  [1]
> Fixes: f784fcea4506 ("HID: sensor-hub: Add
> sensor_hub_input_attr_read_values() for multi-byte reads")
> Cc: stable@vger.kernel.org
> Suggested-by: Jonathan Cameron <jic23@kernel.org>
> Assisted-by: LLM
> Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>


Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>


> ---
> Changes in v3:
> - Replace the raw_size error sentinel with a dedicated teardown flag,
> as
>   suggested by Jonathan Cameron.
> - Let teardown win if it races with a completed response.
> 
> v2:
> https://lore.kernel.org/r/20260912050257.837340-1-lhfff@tju.edu.cn/
> 
>  drivers/hid/hid-sensor-hub.c   | 6 +++++-
>  include/linux/hid-sensor-hub.h | 2 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-
> hub.c
> index 6470a290ebfc..a9bd72218c07 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -334,6 +334,8 @@ int sensor_hub_input_attr_read_values(struct
> hid_sensor_hub_device *hsdev,
>  			ret = -ETIMEDOUT;
>  		else if (cycles < 0)
>  			ret = cycles;
> +		else if (hsdev->pending.shutdown)
> +			ret = -ENODEV;
>  
>  		hsdev->pending.status = false;
>  	}
> @@ -805,8 +807,10 @@ static int sensor_hub_finalize_pending_fn(struct
> device *dev, void *data)
>  {
>  	struct hid_sensor_hub_device *hsdev = dev->platform_data;
>  
> -	if (hsdev->pending.status)
> +	if (hsdev->pending.status) {
> +		hsdev->pending.shutdown = true;
>  		complete(&hsdev->pending.ready);
> +	}
>  
>  	return 0;
>  }
> diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-
> sensor-hub.h
> index ab5cc8db3fbb..5aecf4474183 100644
> --- a/include/linux/hid-sensor-hub.h
> +++ b/include/linux/hid-sensor-hub.h
> @@ -38,6 +38,7 @@ struct hid_sensor_hub_attribute_info {
>  /**
>   * struct sensor_hub_pending - Synchronous read pending information
>   * @status:		Pending status true/false.
> + * @shutdown:		The device is being removed.
>   * @ready:		Completion synchronization data.
>   * @usage_id:		Usage id for physical device, e.g. gyro
> usage id.
>   * @attr_usage_id:	Usage Id of a field, e.g. X-axis for a gyro.
> @@ -48,6 +49,7 @@ struct hid_sensor_hub_attribute_info {
>   */
>  struct sensor_hub_pending {
>  	bool status;
> +	bool shutdown;
>  	struct completion ready;
>  	u32 usage_id;
>  	u32 attr_usage_id;

Re: [PATCH v3] HID: sensor-hub: Fail unfinished multi-value reads on removal

Posted by Jonathan Cameron 1 week, 4 days ago

On Sun, 13 Sep 2026 08:50:35 -0700
srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:

> On Sun, 2026-09-13 at 15:29 +0800, Yibo Tan wrote:
> > sensor_hub_remove() completes pending reads after stopping the HID
> > device,
> > but does not record why they completed.  A successful completion wait
> > therefore returns zero even if no complete input report was received.
> > Multi-value IIO callers then format their untouched automatic buffer
> > as a
> > successful result.
> > 
> > With a valid four-element signed 32-bit quaternion report descriptor,
> > an
> > unprivileged reader received all 16 bytes of the untouched buffer. 
> > Across
> > 11 independent KASLR-enabled boots, four reads exposed exact pointers
> > to
> > dev_rot_channels or dev_sysfs_ops.  Subtracting the matching link-
> > time
> > symbol address recovered the kernel KASLR slide in all four cases.
> > 
> > The reader ran as UID/GID 65534 with no effective capabilities
> > through the
> > mode-0644 IIO attribute.  The test used a privileged UHID broker to
> > create
> > and remove the provider; it does not demonstrate unprivileged
> > provider
> > removal.
> > 
> > Mark a pending request as shut down before completing it from the
> > removal
> > path, and return -ENODEV from a multi-value read that observes the
> > marker
> > after a successful wait.  Let removal win even if a response raced
> > with
> > teardown, since the device is no longer available.
> > 
> > The Root B-only repair returned -ENODEV with no payload or kernel
> > diagnostic in 3/3 matching signed-32-bit runs.  The source
> > reproducer,
> > complete vulnerable and fixed serial logs, result tables, and
> > checksums are
> > available in [1].
> > 
> > Link:
> > https://github.com/kimaiden1984-boop/linux-kernel-poc-collections/tree/main/cases/hid-sensor-quaternion-root-b-kaslr
> >  [1]
> > Fixes: f784fcea4506 ("HID: sensor-hub: Add
> > sensor_hub_input_attr_read_values() for multi-byte reads")
> > Cc: stable@vger.kernel.org
> > Suggested-by: Jonathan Cameron <jic23@kernel.org>
> > Assisted-by: LLM
> > Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>  
> 
> 
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

Applied to the fixes branch of iio.git.

It might or might not go upstream before the next merge windows. In practice
I'm going to assume these devices are typically not hotplugable except in
dev kits so we are unlikely to see this on production devices unless
someone manually removes?  That does affect whether to fix it, but only how
fast we rush it upstream!

Jonathan

> 
> 
> > ---
> > Changes in v3:
> > - Replace the raw_size error sentinel with a dedicated teardown flag,
> > as
> >   suggested by Jonathan Cameron.
> > - Let teardown win if it races with a completed response.
> > 
> > v2:
> > https://lore.kernel.org/r/20260912050257.837340-1-lhfff@tju.edu.cn/
> > 
> >  drivers/hid/hid-sensor-hub.c   | 6 +++++-
> >  include/linux/hid-sensor-hub.h | 2 ++
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-
> > hub.c
> > index 6470a290ebfc..a9bd72218c07 100644
> > --- a/drivers/hid/hid-sensor-hub.c
> > +++ b/drivers/hid/hid-sensor-hub.c
> > @@ -334,6 +334,8 @@ int sensor_hub_input_attr_read_values(struct
> > hid_sensor_hub_device *hsdev,
> >  			ret = -ETIMEDOUT;
> >  		else if (cycles < 0)
> >  			ret = cycles;
> > +		else if (hsdev->pending.shutdown)
> > +			ret = -ENODEV;
> >  
> >  		hsdev->pending.status = false;
> >  	}
> > @@ -805,8 +807,10 @@ static int sensor_hub_finalize_pending_fn(struct
> > device *dev, void *data)
> >  {
> >  	struct hid_sensor_hub_device *hsdev = dev->platform_data;
> >  
> > -	if (hsdev->pending.status)
> > +	if (hsdev->pending.status) {
> > +		hsdev->pending.shutdown = true;
> >  		complete(&hsdev->pending.ready);
> > +	}
> >  
> >  	return 0;
> >  }
> > diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-
> > sensor-hub.h
> > index ab5cc8db3fbb..5aecf4474183 100644
> > --- a/include/linux/hid-sensor-hub.h
> > +++ b/include/linux/hid-sensor-hub.h
> > @@ -38,6 +38,7 @@ struct hid_sensor_hub_attribute_info {
> >  /**
> >   * struct sensor_hub_pending - Synchronous read pending information
> >   * @status:		Pending status true/false.
> > + * @shutdown:		The device is being removed.
> >   * @ready:		Completion synchronization data.
> >   * @usage_id:		Usage id for physical device, e.g. gyro
> > usage id.
> >   * @attr_usage_id:	Usage Id of a field, e.g. X-axis for a gyro.
> > @@ -48,6 +49,7 @@ struct hid_sensor_hub_attribute_info {
> >   */
> >  struct sensor_hub_pending {
> >  	bool status;
> > +	bool shutdown;
> >  	struct completion ready;
> >  	u32 usage_id;
> >  	u32 attr_usage_id;  
>