* [PATCH bpf-next v4 0/3] HID: bpf: Fix hid_bpf_get_data() range check
From: Yiyang Chen @ 2026-06-23 6:23 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
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 use check_add_overflow() for the range end
and then compare the computed end against ctx->allocated_size.
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 v4:
- Use check_add_overflow() in hid_bpf_get_data() before comparing the
computed range end against ctx->allocated_size.
- Update the fix commit message to describe the overflow-helper check.
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").
v3: https://lore.kernel.org/bpf/20260622065246.414380-1-chenyy23@mails.tsinghua.edu.cn/
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 | 5 +++-
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, 49 insertions(+), 9 deletions(-)
base-commit: a975094bf98ca97be9146f9d3b5681a6f9cf5ce3
--
2.34.1
^ permalink raw reply
* Re: [PATCH v4] Input: elan_i2c - prevent division by zero and arithmetic underflow
From: Dmitry Torokhov @ 2026-06-23 5:31 UTC (permalink / raw)
To: Ranjan Kumar; +Cc: bleung, bentiss, linux-input, linux-kernel
In-Reply-To: <20260612060339.3829666-1-kumarranja@chromium.org>
On Fri, Jun 12, 2026 at 06:03:39AM +0000, Ranjan Kumar wrote:
> The Elan I2C touchpad driver queries the device for its physical
> dimensions and trace counts to calculate the device resolution and width.
> However, if the device firmware or device tree provides invalid zero
> values for x_traces or y_traces, it results in a fatal division-by-zero
> exception leading to a kernel panic during device probe.
>
> Add checks to ensure these parameters are non-zero before performing
> the division. If invalid trace values are detected, fall back to a safe
> default of 1.
>
> Additionally, prevent an arithmetic underflow in the touch reporting
> logic. Previously, if the calculated or fallback width was smaller than
> ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a
> massive unsigned integer being reported to userspace. Clamp the adjusted
> width to a minimum of 0 to safely handle small physical dimensions and
> fallback scenarios.
>
> Completing the probe with safe fallback values ensures the sysfs nodes
> are created, keeping the firmware update path intact so a recovery
> firmware can be flashed to the device.
>
> Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad")
> Fixes: e3a9a1290688 ("Input: elan_i2c - do not query the info if they are provided")
> Signed-off-by: Ranjan Kumar <kumarranja@chromium.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* 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
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