* Re: [PATCH] Input: synaptics-rmi4 - bound the SMBus block read to the caller buffer
From: Dmitry Torokhov @ 2026-06-23 5:22 UTC (permalink / raw)
To: hexlabsecurity
Cc: Benjamin Tissoires, linux-input, Andrew Duggan, linux-kernel
In-Reply-To: <20260613-b4-disp-2e033955-v1-1-43ab7281667a@proton.me>
On Sat, Jun 13, 2026 at 12:39:32AM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> smb_block_read() takes a destination length but passes it nowhere:
>
> static int smb_block_read(struct rmi_transport_dev *xport,
> u8 commandcode, void *buf, size_t len)
> {
> ...
> retval = i2c_smbus_read_block_data(client, commandcode, buf);
>
> i2c_smbus_read_block_data() has no destination-size argument; it copies
> the block count reported by the device (the first SMBus byte, up to
> I2C_SMBUS_BLOCK_MAX = 32) into buf. The RMI callers pass buffers far
> smaller than 32 bytes - rmi_read_pdt_entry() reads a PDT entry into an
> on-stack u8 buf[RMI_PDT_ENTRY_SIZE] (6 bytes) during the PDT scan - so a
> malfunctioning, malicious or counterfeit RMI4 SMBus controller (or an
> attacker tampering with the I2C bus) that reports a larger block count
> overflows the caller's stack buffer by up to 32 - 6 = 26 bytes,
> clobbering the stack canary, saved registers and the return address.
>
> Read into a local I2C_SMBUS_BLOCK_MAX-sized buffer and copy back at most
> len bytes, so the device can never write past the caller's buffer.
>
> Fixes: 82264d0cf7ae ("Input: synaptics-rmi4 - add SMBus support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
> ---
> drivers/input/rmi4/rmi_smbus.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
> index f3d0b40721df..ea957aba28f1 100644
> --- a/drivers/input/rmi4/rmi_smbus.c
> +++ b/drivers/input/rmi4/rmi_smbus.c
> @@ -177,12 +177,20 @@ static int smb_block_read(struct rmi_transport_dev *xport,
> struct rmi_smb_xport *rmi_smb =
> container_of(xport, struct rmi_smb_xport, xport);
> struct i2c_client *client = rmi_smb->client;
> + u8 data[I2C_SMBUS_BLOCK_MAX];
> int retval;
>
> - retval = i2c_smbus_read_block_data(client, commandcode, buf);
> + /*
> + * i2c_smbus_read_block_data() copies the device-reported block count
> + * (up to I2C_SMBUS_BLOCK_MAX) into the destination and has no way to
> + * know its size, so read into a local buffer and copy back at most
> + * len bytes - never past the caller's buffer.
> + */
> + retval = i2c_smbus_read_block_data(client, commandcode, data);
> if (retval < 0)
> return retval;
>
> + memcpy(buf, data, min_t(size_t, retval, len));
Instead of doing extra copy I'd like to get the following in:
https://lore.kernel.org/all/ZxGrwObOFkNuCn_w@google.com/
But unfortunately it has stalled. Can you try and see if it works for
you?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: iforce - bound the device-reported force-feedback effect index
From: Dmitry Torokhov @ 2026-06-23 3:53 UTC (permalink / raw)
To: hexlabsecurity; +Cc: linux-input, linux-kernel
In-Reply-To: <20260613-b4-disp-4828d263-v1-1-02320e1a89dd@proton.me>
On Sat, Jun 13, 2026 at 09:58:55PM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> iforce_process_packet() handles a status report (packet id 0x02) by
> taking a force-feedback effect index straight from the device wire and
> using it to address the per-effect state array:
>
> i = data[1] & 0x7f;
> if (data[1] & 0x80) {
> if (!test_and_set_bit(FF_CORE_IS_PLAYED,
> iforce->core_effects[i].flags))
> ...
> } else if (test_and_clear_bit(FF_CORE_IS_PLAYED,
> iforce->core_effects[i].flags)) {
> ...
> }
>
> The index is masked only with 0x7f, so it ranges 0..127, but
> core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index
> of 32..127 the test_and_set_bit()/test_and_clear_bit() is an
> out-of-bounds single-bit read-modify-write past the array. core_effects[]
> is the second-to-last member of struct iforce, so the write lands in the
> trailing members and beyond the embedding kzalloc()'d iforce_serio /
> iforce_usb object.
>
> data[1] is unvalidated device payload on both transports (the USB
> interrupt endpoint and serio), and the status path is not gated on force
> feedback being present, so a malicious or counterfeit device can set or
> clear a bit at an attacker-chosen offset past the object.
>
> Reject an out-of-range index instead of indexing with it. Bound against
> the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so
> the check guarantees memory safety regardless of how many effects the
> device registered. A legitimate "effect started/stopped" status always
> carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are
> unaffected; the neighbouring mark_core_as_ready() loop is already bounded
> and is left untouched.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Thank you, applied (but I dropped the temporary 'flags').
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: hid-sensor-custom: Fix sysfs group leak on failure
From: sashiko-bot @ 2026-06-23 2:36 UTC (permalink / raw)
To: Haoxiang Li; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260623021950.1736413-1-haoxiang_li2024@163.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Freeing `sensor_inst->fields` on `sysfs_create_group()` failure creates a Use-After-Free window because the `enable_sensor` sysfs attribute is already active and its store method uses pointers into the `fields` array.
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the driver teardown path frees `sensor_inst->fields` before removing the `enable_sensor` sysfs attribute, allowing a concurrent Use-After-Free.
--
commit 0c3a9f337fe5155646ac08e2a7d6eae0a3e612f0
Author: Haoxiang Li <haoxiang_li2024@163.com>
HID: hid-sensor-custom: Fix sysfs group leak on failure
hid_sensor_custom_add_attributes() creates one sysfs group for each
custom sensor field. If sysfs_create_group() fails after some groups
have already been created, the function currently breaks out of the
loop and returns the error directly.
Fix this by adding a local unwind path when sysfs_create_group() fails.
The unwind path removes all sysfs groups that were successfully created
before the failure and frees sensor_inst->fields.
> diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
> index afffea8940214..cd676516e6b04 100644
> --- a/drivers/hid/hid-sensor-custom.c
> +++ b/drivers/hid/hid-sensor-custom.c
[ ... ]
> @@ -621,6 +621,13 @@ static int hid_sensor_custom_add_attributes(struct hid_sensor_custom
> }
>
> return ret;
> +
> +err_remove_groups:
> + while (--i >= 0)
> + sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
> + &sensor_inst->fields[i].hid_custom_attribute_group);
> + kfree(sensor_inst->fields);
[Severity: High]
Does freeing sensor_inst->fields here introduce a use-after-free window?
Because hid_sensor_custom_probe() registers the enable_sensor sysfs group
before this function is called, the sysfs file is accessible during this
failure unwind window.
If a concurrent write to enable_sensor triggers enable_sensor_store(), it
will dereference sensor_inst->power_state and sensor_inst->report_state in
set_power_report_state(). Since those pointers point into the freed
sensor_inst->fields array and are not cleared here, this might cause memory
corruption.
> + return ret;
> }
>
> static void hid_sensor_custom_remove_attributes(struct hid_sensor_custom *
[Severity: High]
This isn't a bug introduced by this patch, but the driver teardown path has a
similar issue.
In hid_sensor_custom_remove(), the code calls
hid_sensor_custom_remove_attributes() which unconditionally frees
sensor_inst->fields. Only after this does it call sysfs_remove_group() to
remove the enable_sensor_attr_group.
Could a concurrent sysfs write during this window trigger
enable_sensor_store(), causing it to dereference the dangling
sensor_inst->power_state pointer in set_power_report_state()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623021950.1736413-1-haoxiang_li2024@163.com?part=1
^ permalink raw reply
* [PATCH] HID: hid-sensor-custom: Fix sysfs group leak on failure
From: Haoxiang Li @ 2026-06-23 2:19 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada, bentiss
Cc: linux-input, linux-iio, linux-kernel, Haoxiang Li, stable
hid_sensor_custom_add_attributes() creates one sysfs group for each
custom sensor field. If sysfs_create_group() fails after some groups
have already been created, the function currently breaks out of the
loop and returns the error directly.
Fix this by adding a local unwind path when sysfs_create_group() fails.
The unwind path removes all sysfs groups that were successfully created
before the failure and frees sensor_inst->fields.
Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
drivers/hid/hid-sensor-custom.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
index afffea894021..cd676516e6b0 100644
--- a/drivers/hid/hid-sensor-custom.c
+++ b/drivers/hid/hid-sensor-custom.c
@@ -609,7 +609,7 @@ static int hid_sensor_custom_add_attributes(struct hid_sensor_custom
&sensor_inst->fields[i].
hid_custom_attribute_group);
if (ret)
- break;
+ goto err_remove_groups;
/* For power or report field store indexes */
if (sensor_inst->fields[i].attribute.attrib_id ==
@@ -621,6 +621,13 @@ static int hid_sensor_custom_add_attributes(struct hid_sensor_custom
}
return ret;
+
+err_remove_groups:
+ while (--i >= 0)
+ sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
+ &sensor_inst->fields[i].hid_custom_attribute_group);
+ kfree(sensor_inst->fields);
+ return ret;
}
static void hid_sensor_custom_remove_attributes(struct hid_sensor_custom *
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3] HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver
From: 谢致邦 (XIE Zhibang) @ 2026-06-23 2:05 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov, bentiss
Cc: Yeking, dianders, jikos, linux-kernel, sashiko-bot,
sashiko-reviews, superm1
In-Reply-To: <0ff827b8-4690-4ec7-9025-6816befd1d7b@kernel.org>
Hi Hans, hi Benjamin,
On Tue, Jun 09, 2026 at 03:07:53PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9-Jun-26 12:10, 谢致邦 (XIE Zhibang) wrote:
> > Hi Hans,
> >
> > Thanks for the review.
> >
> > The current header-based approach lets i2c-hid-acpi-prp0001.c work
> > independently by just including a header for the _DSM helper. Switching
> > to EXPORT_SYMBOL_GPL would force prp0001 to depend on i2c-hid-acpi —
> > a Kconfig "depends on I2C_HID_ACPI", plus module-level dependency at
> > load time — all for sharing a single function. I find that hard to
> > accept.
> >
> > I understand that adding a new header for one prototype is unusual,
> > though it contains only a single static inline function and introduces
> > no runtime dependency between the two drivers.
> >
> > Looking back at the full discussion: Benjamin made it clear from the
> > start that he doesn't want i2c-hid-of.c handling ACPI _DSM fallback.
> > His line is that ACPI devices and OF devices should each go through
> > their own drivers without cross-contamination. If you still prefer
> > exporting the function from i2c-hid-acpi.c, then prp0001 would have to
> > drag i2c-hid-acpi along with it — an independent leaf driver turned
> > into something that can't stand alone.
>
> Well it is a special case/version of the ACPI driver so depending
> on it seems fine to me.
>
> Anyways if you prefer the inline function in header solution that is
> fine with me.
>
> Lets see what bentiss has to say about this.
>
> Regards,
>
> Hans
>
Friendly ping — v5 was posted on Jun 12:
https://lore.kernel.org/all/tencent_8AE8ED913FEC8151B4BA3D85D6BB7F3ACF08@qq.com/
No further review comments have come in.
Is there anything else you'd like changed, or can we move forward?
Regards,
Zhibang
^ permalink raw reply
* Re: [PATCH] Input: yealink - stop URB resubmission on completion error
From: Dmitry Torokhov @ 2026-06-23 1:16 UTC (permalink / raw)
To: Wang, Jie
Cc: Henk Vergonet, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org,
syzbot+039eab266c6321a174bd@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com
In-Reply-To: <DS0PR11MB64484A4A38381336F2AC0C3F98E42@DS0PR11MB6448.namprd11.prod.outlook.com>
On Wed, Jun 17, 2026 at 05:49:07AM +0000, Wang, Jie wrote:
> Hi Dmitry,
>
> Thank you for the review.
>
> > -----Original Message-----
> > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Sent: Wednesday, June 17, 2026 3:17 AM
> > To: Wang, Jie <jie.wang@intel.com>
> > Cc: Henk Vergonet <Henk.Vergonet@gmail.com>; linux-input@vger.kernel.org;
> > linux-kernel@vger.kernel.org;
> > syzbot+039eab266c6321a174bd@syzkaller.appspotmail.com; syzkaller-
> > bugs@googlegroups.com
> > Subject: Re: [PATCH] Input: yealink - stop URB resubmission on completion error
> >
> > Hi Jie,
> >
> > On Tue, Jun 16, 2026 at 11:04:40AM +0000, Jie Wang wrote:
> > > urb_irq_callback() and urb_ctl_callback() resubmit each other's URBs
> > > regardless of completion status. When the device returns a persistent
> > > error (-EPROTO), this creates an unthrottled resubmission loop that
> > > starves the CPU and triggers RCU stalls.
> > >
> > > Stop resubmitting on any non-zero URB status, following the standard
> > > completion pattern used by other USB input drivers.
> > >
> > > Reported-by: syzbot+039eab266c6321a174bd@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=039eab266c6321a174bd
> > > Signed-off-by: Jie Wang <jie.wang@intel.com>
> >
> > It would be good to have a helper like
> >
> > bool usb_is_permanent_error(struct urb *urb, struct device *dev);
> >
> > instead of having this "switch" in all the drivers. It also unclear whether we should
> > not attempt to re-submit the URB on errors other than ECONNRESET, ENOENT, or
> > ESHUTDOWN.
> >
>
> For the helper - how about a local yealink_urb_check_status() in v2?
> A usb_is_permanent_error() in usb.h would benefit more drivers
> across the tree, but that's a larger effort best done separately.
I do not think we are in a rush to fix this: the driver is old and I
have no idea how many users actually have the device.
>
> For resubmission - I'm thinking stop immediately on -ECONNRESET,
> -ENOENT, -ESHUTDOWN, and for
> everything else retry up to 50 consecutive errors before giving up.
> Counter resets on any successful completion, so transient bus glitches
> recover but a dead device won't spin thThat is probably reasonable.e CPU forever.
That is sounds reasonable.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: synaptics - enable Synaptics InterTouch for ThinkPad X270
From: Mark Alexander @ 2026-06-22 21:44 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Mark Alexander
On a ThinkPad X270, I see this in /var/log/messages:
Jun 20 07:28:11 x270 kernel: psmouse serio1: synaptics: Your touchpad (PNP: LEN2046 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
Add LEN2046 to the SMB list to eliminate this warning.
Tested on a ThinkPad X270 with kernel 7.1.0 and Fedora 43.
Signed-off-by: Mark Alexander <marka@pobox.com>
---
drivers/input/mouse/synaptics.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index c70502e240..0684e25b2a 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -188,6 +188,7 @@ static const char * const smbus_pnp_ids[] = {
"LEN0411", /* L14 Gen 1 */
"LEN200f", /* T450s */
"LEN2044", /* L470 */
+ "LEN2046", /* X270 */
"LEN2054", /* E480 */
"LEN2055", /* E580 */
"LEN2058", /* E490 */
--
2.54.0
--
Mark Alexander marka@pobox.com
^ permalink raw reply related
* Re: [PATCH v1] iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register()
From: srinivas pandruvada @ 2026-06-22 20:50 UTC (permalink / raw)
To: Maxwell Doose
Cc: Sanjay Chitroda, jikos, jic23, dlechner, nuno.sa, andy,
hongyan.song, linux-input, linux-iio, linux-kernel
In-Reply-To: <CAKqfh0Hk12rA7wkU9wbse=n9qbOgbmxK0vhP6Enj-R2yKCohuQ@mail.gmail.com>
On Mon, 2026-06-22 at 10:27 -0500, Maxwell Doose wrote:
> On Mon, Jun 22, 2026 at 10:26 AM srinivas pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> >
> > On Mon, 2026-06-22 at 10:51 +0530, Sanjay Chitroda wrote:
> > > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> > >
> > > Avoid using devm_iio_device_register(), as this driver requires
> > > explicit
> > > error handling and teardown ordering.
> > >
> > > Mixing devm_* APIs with goto-based error unwinding breaks the
> > > expected
> > > LIFO resource release model and can introduce race windows during
> > > device
> > > removal. In particular, the IIO device may remain visible to
> > > userspace
> > > while dependent resources are already being freed, potentially
> > > leading
> > > to use-after-free issues.
> >
> > Please explain this use after free case here.
> >
> > Thanks,
> > Srinivas
>
> My guess is that because the device would still be registered but
> would actually be removed, sysfs still has "wild" pointers to
> read_raw() and write_raw() (which don't exist anymore), causing the
> UAF. If I'm wrong feel free to correct me though.
iio_device_unregister() will be last one to be called after device
removal from devm action handler. This will cleanup attributes. So,
read_raw() or write_raw() can be called. The problem can be handlers
for read_raw() and write_raw() if anything there which are dependent on
clean done by hid_temperature_remove(). Here callbacks are cleaned up,
so nothing to respond to read sensor_hub_input_attr_get_raw_value(),
so it has to wait for 5 seconds to timeout, which is not great. So
nothing against change done here.
But still not sure any use after free case, unless I am missing
something.
Thanks,
Srinivas
^ permalink raw reply
* [syzbot] Monthly input report (Jun 2026)
From: syzbot @ 2026-06-22 20:32 UTC (permalink / raw)
To: linux-input, linux-kernel, syzkaller-bugs
Hello input maintainers/developers,
This is a 31-day syzbot report for the input subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/input
During the period, 1 new issues were detected and 0 were fixed.
In total, 18 issues are still open and 63 have already been fixed.
There are also 4 low-priority issues.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 2096 No possible deadlock in evdev_pass_values (2)
https://syzkaller.appspot.com/bug?extid=13d3cb2a3dc61e6092f5
<2> 705 Yes KASAN: slab-out-of-bounds Read in mcp2221_raw_event (2)
https://syzkaller.appspot.com/bug?extid=1018672fe70298606e5f
<3> 215 Yes WARNING in cm109_input_open/usb_submit_urb (3)
https://syzkaller.appspot.com/bug?extid=ac0f9c4cc1e034160492
<4> 122 No KASAN: slab-use-after-free Read in report_descriptor_read
https://syzkaller.appspot.com/bug?extid=bc537ca7a0efe33988eb
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH bpf-next v3 1/3] HID: bpf: Fix hid_bpf_get_data() range check
From: Eduard Zingerman @ 2026-06-22 18:18 UTC (permalink / raw)
To: Yiyang Chen, Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Shuah Khan, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Kumar Kartikeya Dwivedi, Song Liu,
Yonghong Song, Jiri Olsa, linux-kselftest, linux-kernel
In-Reply-To: <20260622073011.423657-1-chenyy23@mails.tsinghua.edu.cn>
On Mon, 2026-06-22 at 07:30 +0000, Yiyang Chen wrote:
> hid_bpf_get_data() returns a pointer into the HID-BPF context data when
> the caller-provided offset and size fit inside ctx->allocated_size.
>
> The current check adds rdwr_buf_size and offset before comparing the
> result against ctx->allocated_size. Since both values are unsigned, a
> very large size can wrap the sum below ctx->allocated_size and make the
> helper return a pointer even though the requested range is not contained
> in the backing buffer.
>
> Use a non-wrapping range check instead: reject offsets beyond the
> allocation, then compare the requested size with the remaining bytes
> after the offset.
>
> Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs")
> Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
> ---
> drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
> index d0130658091b0..09b45c40d84f0 100644
> --- a/drivers/hid/bpf/hid_bpf_dispatch.c
> +++ b/drivers/hid/bpf/hid_bpf_dispatch.c
> @@ -299,7 +299,8 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr
>
> ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
>
> - if (rdwr_buf_size + offset > ctx->allocated_size)
> + if (offset > ctx->allocated_size ||
> + rdwr_buf_size > ctx->allocated_size - offset)
Nit: imo, this is harder to read, I'd define a variable to hold the
buffer end position, update it using check_add_overflow and
then compare it against ctx->allocated_size, e.g.:
if (check_add_overflow(rdwr_buf_size, offset, &end) || end > ctx->allocated_size)
...
pw-bot: cr
> return NULL;
>
> return ctx_kern->data + offset;
^ permalink raw reply
* Re: [PATCH v2 0/8] HID: iio: Avoid race between callback setup and device exposure
From: Pandruvada, Srinivas @ 2026-06-22 15:35 UTC (permalink / raw)
To: dlechner@baylibre.com, archana.patni@linux.intel.com,
hongyan.song@intel.com, nuno.sa@analog.com, jic23@kernel.org,
jikos@kernel.org, andy@kernel.org, sanjayembeddedse@gmail.com
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org
In-Reply-To: <20260622-5-june-hid-iio-race-fixes-v2-0-1cfabcd1881e@gmail.com>
On Mon, 2026-06-22 at 10:59 +0530, Sanjay Chitroda wrote:
> Hi all,
>
> This series avoid a race condition in HID IIO drivers related to the
> ordering between callback registration and device exposure.
>
> Currently, several HID IIO drivers register the IIO device (making it
> visible to userspace and other kernel consumers) before all required
> callbacks and resources are fully initialized, or rely on devm-based
> cleanup in a way that does not guarantee correct teardown ordering.
> This creates a window where the device can be accessed while it is
> not fully initialized or is being torn down, potentially leading to
> sample drop or stale/no data.
>
> To handle this, the series ensures that:
> - All required callbacks and resources are set up before the device
> is registered with the IIO core
> - Resource cleanup is performed explicitly where ordering matters
>
> PS: This is prepratory series to convert all HID IIO driver to devm.
>
> Testing:
> - Compiled with W=1 for each patch in series
>
> ---
> Changes in v2:
> - Drop fixes tag and rectify commit message with reference to that
> - Link to v1:
> https://patch.msgid.link/20260606-5-june-hid-iio-race-fixes-v1-0-27a848c5758f@gmail.com
>
> To: Jiri Kosina <jikos@kernel.org>
> To: Jonathan Cameron <jic23@kernel.org>
> To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> To: David Lechner <dlechner@baylibre.com>
> To: Nuno Sá <nuno.sa@analog.com>
> To: Andy Shevchenko <andy@kernel.org>
> Cc: linux-input@vger.kernel.org
> Cc: linux-iio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> Sanjay Chitroda (8):
> iio: orientation: hid-sensor-rotation: Avoid race between
> callback setup and device exposure
> iio: orientation: hid-sensor-incl-3d: Avoid race between
> callback setup and device exposure
> iio: gyro: hid-sensor-gyro-3d: Avoid race between callback
> setup and device exposure
> iio: pressure: hid-sensor-press: Avoid race between callback
> setup and device exposure
> iio: light: hid-sensor-prox: Avoid race between callback setup
> and device exposure
> iio: light: hid-sensor-als: Avoid race between callback setup
> and device exposure
> iio: magnetometer: hid-sensor-magn-3d: Avoid race between
> callback setup and device exposure
> iio: accel: hid-sensor-accel-3d: Avoid race between callback
> setup and device exposure
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 20 ++++++++++-------
> ---
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 20 ++++++++++-------
> ---
> drivers/iio/light/hid-sensor-als.c | 20 ++++++++++-------
> ---
> drivers/iio/light/hid-sensor-prox.c | 20 ++++++++++-------
> ---
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 ++++++++++-------
> ---
> drivers/iio/orientation/hid-sensor-incl-3d.c | 20 ++++++++++-------
> ---
> drivers/iio/orientation/hid-sensor-rotation.c | 20 ++++++++++-------
> ---
> drivers/iio/pressure/hid-sensor-press.c | 20 ++++++++++-------
> ---
> 8 files changed, 80 insertions(+), 80 deletions(-)
> ---
> base-commit: cc746297b23e89bd5df9f91f3a0ca209e8991763
> change-id: 20260605-5-june-hid-iio-race-fixes-f8b981f82b80
>
> Best regards,
> --
> Sanjay Chitroda <sanjayembeddedse@gmail.com>
^ permalink raw reply
* Re: [PATCH v1] iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register()
From: Maxwell Doose @ 2026-06-22 15:27 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Sanjay Chitroda, jikos, jic23, dlechner, nuno.sa, andy,
hongyan.song, linux-input, linux-iio, linux-kernel
In-Reply-To: <767892206bf6a10de4122f5e1faa8481541170ca.camel@linux.intel.com>
On Mon, Jun 22, 2026 at 10:26 AM srinivas pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> On Mon, 2026-06-22 at 10:51 +0530, Sanjay Chitroda wrote:
> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
> > Avoid using devm_iio_device_register(), as this driver requires
> > explicit
> > error handling and teardown ordering.
> >
> > Mixing devm_* APIs with goto-based error unwinding breaks the
> > expected
> > LIFO resource release model and can introduce race windows during
> > device
> > removal. In particular, the IIO device may remain visible to
> > userspace
> > while dependent resources are already being freed, potentially
> > leading
> > to use-after-free issues.
>
> Please explain this use after free case here.
>
> Thanks,
> Srinivas
My guess is that because the device would still be registered but
would actually be removed, sysfs still has "wild" pointers to
read_raw() and write_raw() (which don't exist anymore), causing the
UAF. If I'm wrong feel free to correct me though.
^ permalink raw reply
* Re: [PATCH v1] iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register()
From: srinivas pandruvada @ 2026-06-22 15:24 UTC (permalink / raw)
To: Sanjay Chitroda, jikos, jic23
Cc: dlechner, nuno.sa, andy, hongyan.song, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20260622052135.1804135-1-sanjayembedded@gmail.com>
On Mon, 2026-06-22 at 10:51 +0530, Sanjay Chitroda wrote:
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> Avoid using devm_iio_device_register(), as this driver requires
> explicit
> error handling and teardown ordering.
>
> Mixing devm_* APIs with goto-based error unwinding breaks the
> expected
> LIFO resource release model and can introduce race windows during
> device
> removal. In particular, the IIO device may remain visible to
> userspace
> while dependent resources are already being freed, potentially
> leading
> to use-after-free issues.
Please explain this use after free case here.
Thanks,
Srinivas
>
> Add explicit iio_device_unregister() call in the teardown path to
> ensure
> deterministic cleanup and follow kernel resource management
> conventions.
>
> Fixes: 59d0f2da3569 ("iio: hid: Add temperature sensor support")
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> ---
> drivers/iio/temperature/hid-sensor-temperature.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/temperature/hid-sensor-temperature.c
> b/drivers/iio/temperature/hid-sensor-temperature.c
> index 9f628a8e5cfb..34bff7e9f3a3 100644
> --- a/drivers/iio/temperature/hid-sensor-temperature.c
> +++ b/drivers/iio/temperature/hid-sensor-temperature.c
> @@ -244,7 +244,7 @@ static int hid_temperature_probe(struct
> platform_device *pdev)
> if (ret)
> goto error_remove_trigger;
>
> - ret = devm_iio_device_register(indio_dev->dev.parent,
> indio_dev);
> + ret = iio_device_register(indio_dev);
> if (ret)
> goto error_remove_callback;
>
> @@ -264,6 +264,7 @@ static void hid_temperature_remove(struct
> platform_device *pdev)
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> struct temperature_state *temp_st = iio_priv(indio_dev);
>
> + iio_device_unregister(indio_dev);
> sensor_hub_remove_callback(hsdev,
> HID_USAGE_SENSOR_TEMPERATURE);
> hid_sensor_remove_trigger(indio_dev, &temp_st-
> >common_attributes);
> }
^ permalink raw reply
* Re: [PATCH v1] iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register()
From: Maxwell Doose @ 2026-06-22 15:18 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
hongyan.song, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260622052135.1804135-1-sanjayembedded@gmail.com>
On Mon, Jun 22, 2026 at 12:21 AM Sanjay Chitroda
<sanjayembeddedse@gmail.com> wrote:
>
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> Avoid using devm_iio_device_register(), as this driver requires explicit
> error handling and teardown ordering.
>
> Mixing devm_* APIs with goto-based error unwinding breaks the expected
> LIFO resource release model and can introduce race windows during device
> removal. In particular, the IIO device may remain visible to userspace
> while dependent resources are already being freed, potentially leading
> to use-after-free issues.
>
> Add explicit iio_device_unregister() call in the teardown path to ensure
> deterministic cleanup and follow kernel resource management conventions.
>
> Fixes: 59d0f2da3569 ("iio: hid: Add temperature sensor support")
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> ---
> drivers/iio/temperature/hid-sensor-temperature.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
My rb will be a tad redundant but
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
and should Cc stable as Andy said but hopefully Jonathan can amend :)
--
best regards,
max
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: input: Add binding for Qualcomm SPMI PMIC haptics
From: Krzysztof Kozlowski @ 2026-06-22 12:43 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <20fa15e1-316b-44fa-b59d-99cb7fe78bb0@oss.qualcomm.com>
On 22/06/2026 04:28, Fenglin Wu wrote:
>
> On 6/19/2026 12:18 PM, Krzysztof Kozlowski wrote:
>> On 17/06/2026 13:02, Fenglin Wu wrote:
>>> On 6/17/2026 6:35 PM, Krzysztof Kozlowski wrote:
>>>> On Tue, Jun 16, 2026 at 03:08:24AM -0700, Fenglin Wu wrote:
>>>>> ....
>>>>> +
>>>>> + qcom,lra-period-us:
>>>>> + description:
>>>>> + LRA actuator initial resonance period in microseconds
>>>>> + (1,000,000 / resonant_freq_hz). Used to configure T_LRA-based play
>>>>> + rates and the auto-resonance zero-crossing window.
>>>> This does not feel like static characteristic. Isn't period depending on
>>>> intensity of vibration you want to have? Why would that be fixed per
>>>> board?
>>> This period is specifically used for playbacks that require
>>> auto-resonance to be enabled, which I referred to as "T_LRA-based" and
>>> "auto-resonance zero-crossing window." It plays a key role in the
>>> "DIRECT_PLAY" mode, which produces a constant vibration effect. To
>>> adjust the vibration intensity during this constant effect, the hardware
>>> does it by scaling the peak voltage of the driver signals, rather than
>>> changing the frequency.
>> But maybe changing frequency runtime still would be useful?
> It could be, but the LRA F0 (resonant frequency) still needs to be the
> starting point. You can control vibration intensity by driving the LRA
> slightly off resonance by a given percentage—for example, to reach 50%
> vibration, you could probably drive it 10% off resonant frequency, and
> that mapping also depends on the LRA characteristic. Keep in mind that
> LRA is a spring-mass resonant system, so its output is not linear with
> driving frequency; it is a High_Q system, and its output actually shows
> a sharp peak at the resonance point. By contrast, the relationship
> between driving voltage and its output is much more linear, so scaling
> vibration intensity by adjusting the driving voltage is easier to
> control. Qcom haptics HW scales vibration intensity in DIRECT_PLAY mode
> (for constant vibration effect) by scaling the driving voltage instead.
> That said, the HW can also change the driving waveform frequency by
> updating the T-LRA registers, and this property has to be specified as
> an initial value; otherwise, you won't have a baseline to achieve that.
>
OK, property is fine.
Best regards,
Krzysztof
^ permalink raw reply
* HID: hid-goodix-spi: out of bounds read in goodix_hid_irq()
From: Maoyi Xie @ 2026-06-22 11:17 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel
Hi all,
I think goodix_hid_irq() in drivers/hid/hid-goodix-spi.c can leak kernel
memory to a hidraw reader when a malicious touchscreen reports a large
package size. I would appreciate it if you could take a look.
The handler reads a coordinate event over SPI. It then passes a device
controlled length straight to hid_input_report().
if (le16_to_cpu(pkg->size) < GOODIX_HID_PKG_LEN_SIZE) {
dev_err(ts->dev, "invalid coordinate event package size, %d",
le16_to_cpu(pkg->size));
return IRQ_HANDLED;
}
hid_input_report(ts->hid, HID_INPUT_REPORT, pkg->data,
le16_to_cpu(pkg->size) - GOODIX_HID_PKG_LEN_SIZE, 1);
pkg->size is a __le16 from the device. The only check is a lower bound.
There is no upper bound. So pkg->size can be up to 65535, while pkg->data
only holds GOODIX_HID_COOR_DATA_LEN (82) bytes read into event_buf.
The length reaches hid_input_report(), which passes it as both the buffer
size and the report size.
return __hid_input_report(hid, type, data, size, size, interrupt, ...);
Those two are equal, so the bsize < csize guard in hid_report_raw_event()
never fires. The device length then flows into the hidraw path.
if (hid->claimed & HID_CLAIMED_HIDRAW)
ret = hidraw_report_event(hid, data, size);
hidraw_report_event() does kmemdup(data, size) for each open reader. That
copies up to about 65 KB starting at pkg->data, far past the 82 valid bytes.
The bytes land in the buffer a hidraw client reads back. So it is an out of
bounds read of kernel slab memory handed to user space.
This needs a malicious or compromised Goodix SPI touchscreen and an open
/dev/hidraw node. The open node is common, since libinput and similar tools
keep one. It is not reachable from a VM or syzkaller, only from the SPI
device.
I reproduced the read on 7.1-rc7. I registered a HID device, opened a hidraw
reader, and called hid_input_report() with a small buffer and a large size.
The kmemdup copy faults.
BUG: unable to handle page fault for address ... (in memcpy_orig)
Call Trace:
kmemdup_noprof
hidraw_report_event
hid_report_raw_event
__hid_input_report
An upper bound on pkg->size before the call would close it. The driver
already has the lower bound. A matching upper bound against the bytes read
into event_buf would fit that check. The second hid_input_report() call
further down has the same shape.
Does this look like a real bug to you, and is an upper bound on pkg->size
the right fix? If so I am happy to send a proper patch with a Fixes tag and
Cc stable.
Thanks,
Maoyi
https://maoyixie.com/
^ permalink raw reply
* Re: [PATCH v1] iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register()
From: Andy Shevchenko @ 2026-06-22 10:25 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
hongyan.song, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260622052135.1804135-1-sanjayembedded@gmail.com>
On Mon, Jun 22, 2026 at 10:51:35AM +0530, Sanjay Chitroda wrote:
> Avoid using devm_iio_device_register(), as this driver requires explicit
> error handling and teardown ordering.
>
> Mixing devm_* APIs with goto-based error unwinding breaks the expected
> LIFO resource release model and can introduce race windows during device
> removal. In particular, the IIO device may remain visible to userspace
> while dependent resources are already being freed, potentially leading
> to use-after-free issues.
>
> Add explicit iio_device_unregister() call in the teardown path to ensure
> deterministic cleanup and follow kernel resource management conventions.
Strictly speaking this needs Cc: stable@ as well as mentioned in the
documentation.
LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] HID: nintendo: fix clang build of switch2_probe guard/goto
From: Ryan McClelland @ 2026-06-22 9:47 UTC (permalink / raw)
To: vi, dmitry.torokhov, jikos, bentiss, linux-input; +Cc: s.jegen, Ryan McClelland
In-Reply-To: <20260512200051.2534081-2-vi@endrift.com>
clang rejects the forward `goto err_close/err_stop` in switch2_probe()
because they jump across the scope of the `guard(mutex)(&ns2->lock)`
cleanup variable ("cannot jump from this goto statement to its label").
All three early error paths run before the lock is acquired, so replace
the gotos with explicit hid_hw_close()/hid_hw_stop() cleanup and drop the
now-unused labels. No functional change; gcc accepted the original.
Signed-off-by: Ryan McClelland <rymcclel@gmail.com>
---
Hi Vicki, I've been testing your Switch 2 series on a local machine here
with JC2, GC, and Pro all over USB and hits this clang build break, Patch below
, feel free to just squash it in.
drivers/hid/hid-nintendo.c:4147:3: error: cannot jump from this goto
statement to its label
drivers/hid/hid-nintendo.c:4153:3: error: cannot jump from this goto
statement to its label
with the explanatory notes pointing at:
note: jump bypasses initialization of variable with __attribute__((cleanup))
guard(mutex)(&ns2->lock);
drivers/hid/hid-nintendo.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 40f57036d810..6a286d49e5bd 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -4144,13 +4144,16 @@ static int switch2_probe(struct hid_device *hdev, const struct hid_device_id *id
ret = hid_hw_open(hdev);
if (ret) {
hid_err(hdev, "hw_open failed %d\n", ret);
- goto err_stop;
+ hid_hw_stop(hdev);
+ return ret;
}
ns2 = switch2_get_controller(phys);
if (IS_ERR(ns2)) {
ret = PTR_ERR(ns2);
- goto err_close;
+ hid_hw_close(hdev);
+ hid_hw_stop(hdev);
+ return ret;
}
guard(mutex)(&ns2->lock);
@@ -4194,13 +4197,6 @@ static int switch2_probe(struct hid_device *hdev, const struct hid_device_id *id
return switch2_init_controller(ns2);
return 0;
-
-err_close:
- hid_hw_close(hdev);
-err_stop:
- hid_hw_stop(hdev);
-
- return ret;
}
static void switch2_remove(struct hid_device *hdev)
--
2.54.0
^ permalink raw reply related
* [PATCH bpf-next v3 3/3] selftests/hid: Cover hid_bpf_get_data() size overflow
From: Yiyang Chen @ 2026-06-22 7:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
In-Reply-To: <20260622073011.423657-1-chenyy23@mails.tsinghua.edu.cn>
Add a HID-BPF regression check for hid_bpf_get_data() requests whose
size would overflow when added to the offset.
The new rdesc fixup callback asks for offset 2 and size ~0ULL, then
records whether the helper returns NULL. A vulnerable kernel returns a
non-NULL pointer because the runtime check wraps the addition. A fixed
kernel rejects the request. The test only checks the helper result and
does not dereference the returned pointer.
The callback reports the helper result through BSS and returns 0
intentionally. hid_rdesc_fixup return values are consumed as report
descriptor fixup results, so a positive test-result value would be
interpreted as a replacement report descriptor size.
Also add KHDR_INCLUDES to the HID selftest build so hid_bpf.c sees the
current kernel UAPI HID definitions on systems whose installed headers do
not provide enum hid_report_type.
Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs")
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
---
tools/testing/selftests/hid/Makefile | 2 +-
tools/testing/selftests/hid/hid_bpf.c | 11 +++++++++++
tools/testing/selftests/hid/progs/hid.c | 15 +++++++++++++++
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/hid/Makefile b/tools/testing/selftests/hid/Makefile
index 50ec9e0406aba..357c6eb5ff5ee 100644
--- a/tools/testing/selftests/hid/Makefile
+++ b/tools/testing/selftests/hid/Makefile
@@ -24,7 +24,7 @@ CXX ?= $(CROSS_COMPILE)g++
HOSTPKG_CONFIG := pkg-config
-CFLAGS += -g -O0 -rdynamic -Wall -Werror -I$(OUTPUT)
+CFLAGS += -g -O0 -rdynamic -Wall -Werror -I$(OUTPUT) $(KHDR_INCLUDES)
CFLAGS += -I$(OUTPUT)/tools/include
LDLIBS += -lelf -lz -lrt -lpthread
diff --git a/tools/testing/selftests/hid/hid_bpf.c b/tools/testing/selftests/hid/hid_bpf.c
index 269256e1decd8..b851339308c21 100644
--- a/tools/testing/selftests/hid/hid_bpf.c
+++ b/tools/testing/selftests/hid/hid_bpf.c
@@ -898,6 +898,17 @@ TEST_F(hid_bpf, test_rdesc_fixup)
ASSERT_EQ(rpt_desc.value[4], 0x42);
}
+TEST_F(hid_bpf, test_rdesc_fixup_get_data_overflow)
+{
+ const struct test_program progs[] = {
+ { .name = "hid_rdesc_fixup_get_data_overflow" },
+ };
+
+ LOAD_PROGRAMS(progs);
+
+ ASSERT_EQ(self->skel->bss->get_data_overflow_check, 1);
+}
+
static int libbpf_print_fn(enum libbpf_print_level level,
const char *format, va_list args)
{
diff --git a/tools/testing/selftests/hid/progs/hid.c b/tools/testing/selftests/hid/progs/hid.c
index 5ecc845ef7921..b21fbb13c926f 100644
--- a/tools/testing/selftests/hid/progs/hid.c
+++ b/tools/testing/selftests/hid/progs/hid.c
@@ -13,6 +13,7 @@ struct attach_prog_args {
__u64 callback_check = 52;
__u64 callback2_check = 52;
+__u64 get_data_overflow_check;
SEC("?struct_ops/hid_device_event")
int BPF_PROG(hid_first_event, struct hid_bpf_ctx *hid_ctx, enum hid_report_type type)
@@ -240,6 +241,20 @@ struct hid_bpf_ops rdesc_fixup = {
.hid_rdesc_fixup = (void *)hid_rdesc_fixup,
};
+SEC("?struct_ops.s/hid_rdesc_fixup")
+int BPF_PROG(hid_rdesc_fixup_get_data_overflow, struct hid_bpf_ctx *hid_ctx)
+{
+ if (!hid_bpf_get_data(hid_ctx, 2 /* offset */, ~0ULL /* size */))
+ get_data_overflow_check = 1;
+
+ return 0;
+}
+
+SEC(".struct_ops.link")
+struct hid_bpf_ops rdesc_fixup_get_data_overflow = {
+ .hid_rdesc_fixup = (void *)hid_rdesc_fixup_get_data_overflow,
+};
+
SEC("?struct_ops/hid_device_event")
int BPF_PROG(hid_test_insert1, struct hid_bpf_ctx *hid_ctx, enum hid_report_type type)
{
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next v3 2/3] selftests/hid: Load only requested struct_ops maps
From: Yiyang Chen @ 2026-06-22 7:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
In-Reply-To: <20260622073011.423657-1-chenyy23@mails.tsinghua.edu.cn>
The HID selftest skeleton contains several struct_ops maps, but each test
usually wants to load only the programs named by that test.
load_programs() disabled auto-attach for all maps, but left struct_ops
autocreate enabled. libbpf can enable autoload for programs referenced by
autocreated struct_ops maps, so an unrelated program can be loaded and fail
even when the current test does not use it.
Disable autocreate for all struct_ops maps by default, then re-enable it
only for the maps selected by the test before loading the skeleton.
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
---
tools/testing/selftests/hid/hid_bpf.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/hid/hid_bpf.c b/tools/testing/selftests/hid/hid_bpf.c
index 1e979fb3542ba..269256e1decd8 100644
--- a/tools/testing/selftests/hid/hid_bpf.c
+++ b/tools/testing/selftests/hid/hid_bpf.c
@@ -86,6 +86,20 @@ static void load_programs(const struct test_program programs[],
self->skel = hid__open();
ASSERT_OK_PTR(self->skel) TEARDOWN_LOG("Error while calling hid__open");
+ /*
+ * Disable all struct_ops maps by default so libbpf does not autoload
+ * programs referenced by maps that are unrelated to the current test.
+ */
+ bpf_object__for_each_map(iter_map, *self->skel->skeleton->obj) {
+ if (bpf_map__type(iter_map) == BPF_MAP_TYPE_STRUCT_OPS) {
+ err = bpf_map__set_autocreate(iter_map, false);
+ ASSERT_OK(err) TH_LOG("can not disable struct_ops map '%s'",
+ bpf_map__name(iter_map));
+ }
+
+ bpf_map__set_autoattach(iter_map, false);
+ }
+
for (int i = 0; i < progs_count; i++) {
struct bpf_program *prog;
struct bpf_map *map;
@@ -102,6 +116,10 @@ static void load_programs(const struct test_program programs[],
ASSERT_OK_PTR(map) TH_LOG("can not find struct_ops by name '%s'",
programs[i].name + 4);
+ err = bpf_map__set_autocreate(map, true);
+ ASSERT_OK(err) TH_LOG("can not enable struct_ops map '%s'",
+ programs[i].name + 4);
+
/* hid_id is the first field of struct hid_bpf_ops */
ops_hid_id = bpf_map__initial_value(map, NULL);
ASSERT_OK_PTR(ops_hid_id) TH_LOG("unable to retrieve struct_ops data");
@@ -109,13 +127,6 @@ static void load_programs(const struct test_program programs[],
*ops_hid_id = self->hid.hid_id;
}
- /* we disable the auto-attach feature of all maps because we
- * only want the tested one to be manually attached in the next
- * call to bpf_map__attach_struct_ops()
- */
- bpf_object__for_each_map(iter_map, *self->skel->skeleton->obj)
- bpf_map__set_autoattach(iter_map, false);
-
err = hid__load(self->skel);
ASSERT_OK(err) TH_LOG("hid_skel_load failed: %d", err);
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next v3 1/3] HID: bpf: Fix hid_bpf_get_data() range check
From: Yiyang Chen @ 2026-06-22 7:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
In-Reply-To: <20260622065246.414380-1-chenyy23@mails.tsinghua.edu.cn>
hid_bpf_get_data() returns a pointer into the HID-BPF context data when
the caller-provided offset and size fit inside ctx->allocated_size.
The current check adds rdwr_buf_size and offset before comparing the
result against ctx->allocated_size. Since both values are unsigned, a
very large size can wrap the sum below ctx->allocated_size and make the
helper return a pointer even though the requested range is not contained
in the backing buffer.
Use a non-wrapping range check instead: reject offsets beyond the
allocation, then compare the requested size with the remaining bytes
after the offset.
Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs")
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index d0130658091b0..09b45c40d84f0 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -299,7 +299,8 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr
ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
- if (rdwr_buf_size + offset > ctx->allocated_size)
+ if (offset > ctx->allocated_size ||
+ rdwr_buf_size > ctx->allocated_size - offset)
return NULL;
return ctx_kern->data + offset;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v9 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-06-22 7:23 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Julien Massot, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260621081634.467858-4-l.scorcia@gmail.com>
On Sun, Jun 21, 2026 at 10:13:28AM +0200, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 112 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 23 ++++
> 2 files changed, 135 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH bpf-next v3 0/3] HID: bpf: Fix hid_bpf_get_data() range check
From: Yiyang Chen @ 2026-06-22 6:52 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
In-Reply-To: <cover.1781964949.git.chenyy23@mails.tsinghua.edu.cn>
hid_bpf_get_data() exposes a pointer into the HID-BPF context data when
the caller-provided offset and size fit inside ctx->allocated_size.
The helper currently checks that range with:
rdwr_buf_size + offset > ctx->allocated_size
Since both operands are unsigned, a very large size can wrap the sum and
make an out-of-range request look valid.
Patch 1 changes the helper to reject offset values beyond the allocation
and then compare the requested size against the remaining bytes.
Patch 2 updates the HID selftest loader to create only the struct_ops
maps requested by the current test, so unrelated programs from the shared
HID-BPF skeleton are not autoloaded.
Patch 3 adds a HID-BPF regression check that asks hid_bpf_get_data() for
offset 2 and size ~0ULL from an rdesc_fixup callback and expects NULL.
It also adds KHDR_INCLUDES to the HID selftest build so the userspace
test sees current kernel UAPI HID definitions.
Changes in v3:
- Split out a HID selftest loader fix that disables autocreate for
unrelated struct_ops maps.
- Add a Fixes tag to the selftest patch.
- Keep the BSS result flag in the rdesc fixup callback and explain why
the callback must still return 0.
Changes in v2:
- Drop the temporary data variable around the overflow
hid_bpf_get_data() call in the selftest callback.
- Correct the Fixes tag to commit 658ee5a64fcf ("HID: bpf: allocate
data memory for device_event BPF programs").
v2: https://lore.kernel.org/bpf/cover.1781964949.git.chenyy23@mails.tsinghua.edu.cn/
v1: https://lore.kernel.org/bpf/cover.1781627122.git.chenyy23@mails.tsinghua.edu.cn/
Yiyang Chen (3):
HID: bpf: Fix hid_bpf_get_data() range check
selftests/hid: Load only requested struct_ops maps
selftests/hid: Cover hid_bpf_get_data() size overflow
drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
tools/testing/selftests/hid/Makefile | 2 +-
tools/testing/selftests/hid/hid_bpf.c | 36 ++++++++++++++++++++-----
tools/testing/selftests/hid/progs/hid.c | 15 +++++++++++
4 files changed, 47 insertions(+), 9 deletions(-)
base-commit: a975094bf98ca97be9146f9d3b5681a6f9cf5ce3
--
2.34.1
^ permalink raw reply
* Re: [PATCH v9 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-06-22 6:52 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Val Packett, Louis-Alexis Eyraud,
Julien Massot, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260621081634.467858-2-l.scorcia@gmail.com>
On Sun, Jun 21, 2026 at 10:13:26AM +0200, Luca Leonardo Scorcia wrote:
> - enum:
> - mediatek,mt6359-rtc
> @@ -99,6 +107,7 @@ properties:
> - mediatek,mt6331-regulator
> - mediatek,mt6358-regulator
> - mediatek,mt6359-regulator
> + - mediatek,mt6392-regulator
> - mediatek,mt6397-regulator
> - items:
> - enum:
> @@ -663,3 +672,69 @@ examples:
> compatible = "mediatek,mt6397-rtc";
> };
> };
> +
> + - |
> + #include <dt-bindings/input/input.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + pmic {
> + compatible = "mediatek,mt6392", "mediatek,mt6323";
You already have three examples, that's rather close to max expected
number of them. I suggest dropping.
Anyway,
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 8/8] iio: accel: hid-sensor-accel-3d: Avoid race between callback setup and device exposure
From: sashiko-bot @ 2026-06-22 6:03 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260622-5-june-hid-iio-race-fixes-v2-8-1cfabcd1881e@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Pre-existing Use-After-Free during driver removal or probe failure due to lack of callback synchronization.
- [High] Pre-existing race condition between data push and buffer disable leading to infinite loop.
- [High] Missing length validation on `raw_data` in `accel_3d_capture_sample` leads to out-of-bounds reads and potential Information Leak.
--
commit d6d7cec4acad5d2e20a4e415413ae49c117fe317
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: accel: hid-sensor-accel-3d: Avoid race between callback setup and device exposure
This patch reorders the probe and remove paths in the hid-sensor-accel-3d
driver to ensure callbacks are registered before device exposure and removed
after the device is unregistered. This aims to prevent race conditions where
userspace might enable buffers before callbacks are fully set up.
> diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
> index 42c4259bf2094..12481cfe9800a 100644
> --- a/drivers/iio/accel/hid-sensor-accel-3d.c
> +++ b/drivers/iio/accel/hid-sensor-accel-3d.c
> @@ -386,12 +386,6 @@ static int hid_accel_3d_probe(struct platform_device *pdev)
> return ret;
> }
>
> - ret = iio_device_register(indio_dev);
> - if (ret) {
> - dev_err(&pdev->dev, "device register failed\n");
> - goto error_remove_trigger;
> - }
> -
> accel_state->callbacks.send_event = accel_3d_proc_event;
> accel_state->callbacks.capture_sample = accel_3d_capture_sample;
[Severity: High]
This isn't a bug introduced by this patch, but does this callback setup leave
us vulnerable to an out-of-bounds read?
Looking at accel_3d_capture_sample(), it casts the incoming raw_data pointer
without checking if raw_len is sufficiently large:
accel_3d_capture_sample()
accel_state->scan.accel_val[CHANNEL_SCAN_INDEX_X + offset] =
*(u32 *)raw_data;
Since raw_len is derived directly from the HID report descriptor provided by
the device, could a malicious device declare an artificially small field
(e.g., 1 byte) causing us to read adjacent kernel slab memory when
dereferencing as a u32 or int64_t?
> accel_state->callbacks.pdev = pdev;
> @@ -399,13 +393,19 @@ static int hid_accel_3d_probe(struct platform_device *pdev)
[ ... ]
> @@ -418,8 +418,8 @@ static void hid_accel_3d_remove(struct platform_device *pdev)
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> struct accel_3d_state *accel_state = iio_priv(indio_dev);
>
> - sensor_hub_remove_callback(hsdev, hsdev->usage);
> iio_device_unregister(indio_dev);
[Severity: High]
This isn't a bug introduced by this patch, but could this unregister sequence
trigger an infinite loop during a concurrent data push?
If accel_3d_proc_event() is executing asynchronously in the HID event
context and observes data_ready > 0, it prepares to call
iio_push_to_buffers().
If preempted, another thread could execute this remove path:
hid_accel_3d_remove()
-> iio_device_unregister()
-> iio_disable_all_buffers()
-> iio_buffer_deactivate_all()
-> iio_buffer_deactivate()
iio_buffer_deactivate() uses list_del_init(&buffer->buffer_list), which makes
the list node self-referential. When iio_push_to_buffers() resumes its
lockless list_for_each_entry() traversal, will it infinite loop on this node?
> + sensor_hub_remove_callback(hsdev, hsdev->usage);
[Severity: Critical]
This is a pre-existing issue, but does this callback removal leave a window
for a use-after-free?
sensor_hub_remove_callback() removes the callback from the list under a
spinlock but does not appear to wait for concurrently executing
sensor_hub_raw_event() handlers to complete.
Once hid_accel_3d_remove() returns, the devres framework will immediately
free indio_dev and accel_state. If a concurrent sensor_hub_raw_event() already
fetched the callback pointer:
sensor_hub_raw_event()
if (callback->capture_sample) {
if (report->field[i]->logical)
callback->capture_sample(hsdev, ...);
Could it dereference the freed accel_state to execute capture_sample and
send_event, resulting in a use-after-free?
> hid_sensor_remove_trigger(indio_dev, &accel_state->common_attributes);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-5-june-hid-iio-race-fixes-v2-0-1cfabcd1881e@gmail.com?part=8
^ 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