* Re: [PATCH v3 0/4] ROCK 4D audio enablement
From: Alexandre Belloni @ 2026-06-23 9:47 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, kernel, linux-input, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Krzysztof Kozlowski,
Cristian Ciocaltea
In-Reply-To: <wE1x9P2vQlC8kihOSm9uOA@collabora.com>
Hello Nicolas,
I guess Dmitry is the one that would take patches 1 to 3. You should
probably resend once the merge window has closed.
On 11/05/2026 18:21:40+0200, Nicolas Frattaroli wrote:
> Hi Alexandre, and other maintainers,
>
> On Wednesday, 8 April 2026 19:49:38 Central European Summer Time Nicolas Frattaroli wrote:
> > The ROCK 4D uses an ADC input to distinguish between a headphone (i.e.,
> > no mic) and a headset (i.e., with mic). After some searching, it appears
> > that the closest we can get to modelling this is by sending a particular
> > switch input event.
> >
> > So this series modifies the adc-keys bindings, extends the adc-keys
> > driver to allow sending other input types as well, and then adds the
> > analog audio nodes to ROCK 4D's device tree.
> >
> > It should be noted that analog capture from the TRRS jack currently
> > results in completely digitally silent audio for me, i.e. no data other
> > than 0xFF. There's a few reasons why this could happen, chief among them
> > that my SAI driver is broken or that the ES8328 codec driver is once
> > again broken. The DAPM routes when graphed out look fine though. So the
> > DTS part is correct, and I can fix the broken capture in a separate
> > follow-up patch that doesn't have to include DT people.
> >
> > Another possibility is that my phone headset, despite being 4 rings and
> > having a little pin hole at the back of the volume doodad, does not
> > actually have a microphone, but in that case I'd still expect some noise
> > in the PCM. Maybe it's just shy.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > Changes in v3:
> > - bindings: use unevaluatedProperties instead of explicitly mentioning
> > linux,input-type.
> > - Link to v2: https://lore.kernel.org/r/20251215-rock4d-audio-v2-0-82a61de39b4c@collabora.com
> >
> > Changes in v2:
> > - Drop HDMI audio patch, as it was already merged.
> > - adc-keys: rename "keycode" to "code".
> > - adc-keys: make the keycode (now "code") local a u32 instead of an int
> > - adc-keys: only allow EV_KEY and EV_SW for now. Rename patch
> > accordingly.
> > - adc-keys: Add another patch to rework probe function error logging.
> > - Link to v1: https://lore.kernel.org/r/20250630-rock4d-audio-v1-0-0b3c8e8fda9c@collabora.com
> >
> > ---
> > Nicolas Frattaroli (4):
> > dt-bindings: input: adc-keys: allow all input properties
> > Input: adc-keys - support EV_SW as well, not just EV_KEY.
> > Input: adc-keys - Use dev_err_probe in probe function
> > arm64: dts: rockchip: add analog audio to ROCK 4D
> >
> > .../devicetree/bindings/input/adc-keys.yaml | 17 ++--
> > arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 90 ++++++++++++++++++++++
> > drivers/input/keyboard/adc-keys.c | 88 ++++++++++-----------
> > 3 files changed, 147 insertions(+), 48 deletions(-)
> > ---
> > base-commit: 8de395f35e79d9168a78504fed495578ec7bac52
> > change-id: 20250627-rock4d-audio-cfc07f168a08
> >
> > Best regards,
> > --
> > Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> >
> >
>
> What's the path forward here? All the patches are reviewed, but it
> has been almost a month without them being applied now.
>
> Which tree(s) would this be applied to, and who should I poke?
>
> Thanks :)
>
> Kind regards,
> Nicolas Frattaroli
>
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] Input: synaptics-rmi4 - bound the SMBus block read to the caller buffer
From: Bryam Vargas @ 2026-06-23 7:29 UTC (permalink / raw)
To: Andi Shyti, Dmitry Torokhov
Cc: Benjamin Tissoires, Wolfram Sang, Wolfram Sang, itewqq, linux-i2c,
linux-input, linux-kernel
In-Reply-To: <ajoXuK4DrgSriiww@google.com>
On 2026-06-23, Dmitry Torokhov wrote:
> Wolfram, any chance we could get this in? I am getting patches for OOB
Andi, looping you in -- MAINTAINERS hands I2C to you as of v7.1, and this is
Dmitry's 2024 i2c-core safety patch, which I just retested against current
mainline.
Dmitry, it works. You asked me to try it on the rmi_smbus stack overflow I
reported. On current mainline (master 502d801f0ab0) the patch applies with no
change after ~20 months. i2c-core-smbus.o builds, and so do the unchanged 3-arg
callers (ipmi_ssif, pmbus_core) and the 4-arg form. Nothing takes the address
of i2c_smbus_read_block_data(), so the transition macro compiles for every
caller -- each of the ~82 is a plain 3- or 4-arg call.
The concrete user that was missing in 2024: rmi_read_pdt_entry() reads a PDT
entry into an on-stack u8 buf[6], and smb_block_read() hands that buffer to
i2c_smbus_read_block_data() with no size, so a device reporting a block count
of 7..32 smashes the stack. The 4-arg form bounds it to 6:
- retval = i2c_smbus_read_block_data(client, commandcode, buf);
+ retval = i2c_smbus_read_block_data(client, commandcode, len, buf);
Why 4-arg specifically: the 3-arg default (length = I2C_SMBUS_BLOCK_MAX) is
byte-identical to today's code, so the core patch alone doesn't fix an
undersized caller -- the safety comes from moving each such caller to 4-arg,
which the rmi_smbus conversion above demonstrates.
rmi_smbus is the undersized caller here; the other block-data callers I checked
size to I2C_SMBUS_BLOCK_MAX, so this is the one live conversion for now and the
macro mainly guards the next small buffer.
I build-tested the above on mainline and A/B-verified the bound with a
userspace ASan mirror (-m64 and -m32; the unbounded value is device payload,
not bus timing, so no RMI hardware is needed): 3-arg/today faults for a count
of 7..32 into buf[6], 4-arg is clean for every count. I didn't boot-test a
patched kernel, so I'm not sending a Tested-by tag -- but happy to add one if
you want a specific config exercised.
I can post the rmi_smbus conversion as a formal patch on top of yours (it's
ready, checkpatch-clean), or you can fold it -- whichever you prefer.
Thanks,
Bryam
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Fix FF device cleanup on init failure
From: sashiko-bot @ 2026-06-23 7:07 UTC (permalink / raw)
To: Haoxiang Li; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260623065200.1966629-1-haoxiang_li2024@163.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] Calling `input_ff_destroy(dev)` leaves a dangling `dev->flush` pointer, causing a guaranteed NULL pointer dereference when the device file is closed.
- [High] Calling `input_ff_destroy(dev)` on an active, registered device in the error path introduces a Use-After-Free race condition.
Pre-existing issues:
- [Critical] Use-After-Free in `hidpp_ff_destroy()` due to mismatched lifecycles between `devm`-managed driver data and `input_dev` lifecycle.
- [High] Input device capabilities are initialized after registration, violating subsystem lifecycle rules and exposing incomplete state to userspace.
--
commit 1a99b024f97c7dab9fe8188d726db401b73dd317
Author: Haoxiang Li <haoxiang_li2024@163.com>
HID: logitech-hidpp: Fix FF device cleanup on init failure
hidpp_ff_init() creates the input force-feedback device with
input_ff_create(), then allocates the HID++ FF private data,
effect ID array, and workqueue.
If any of those allocations fail after input_ff_create() succeeds,
the function returns an error without destroying the FF device.
Add an unwind path that frees the private allocations made by
hidpp_ff_init() and calls input_ff_destroy() for failures after
input_ff_create() succeeds.
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index ccbf28869a968..95f84efa77069 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2859,18 +2859,19 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
* ownership to FF core
*/
[Severity: High]
This is a pre-existing issue, but does initializing input device capabilities
after registration violate subsystem lifecycle rules and expose incomplete
state to userspace?
Because hidpp_probe() calls hid_connect() (which registers the device)
before calling hidpp_ff_init(), can userspace open the device and issue
ioctls immediately upon registration, before hidpp_ff_init() has fully
configured the FF capabilities:
for (j = 0; hidpp_ff_effects[j] >= 0; j++)
set_bit(hidpp_ff_effects[j], dev->ffbit);
> data = kmemdup(data, sizeof(*data), GFP_KERNEL);
> - if (!data)
> - return -ENOMEM;
> + if (!data) {
> + error = -ENOMEM;
> + goto err_destroy_ff;
> + }
[ ... ]
> data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
> if (!data->wq) {
> - kfree(data->effect_ids);
> - kfree(data);
> - return -ENOMEM;
> + error = -ENOMEM;
> + goto err_free_effect_ids;
> }
>
> data->hidpp = hidpp;
[Severity: Critical]
This is a pre-existing issue, but could this lead to a use-after-free in
hidpp_ff_destroy() due to mismatched lifecycles?
The hidpp_device structure is allocated using devm_kzalloc() in hidpp_probe(),
meaning it is freed by devres immediately after the driver's remove()
callback completes.
However, the input_dev is reference-counted and outlives the driver binding
if a userspace process holds the event file descriptor open. When the process
finally closes the fd, input_free_device() calls hidpp_ff_destroy(), which
dereferences data->hidpp to access hid_dev:
struct hid_device *hid = data->hidpp->hid_dev;
Could this trigger a use-after-free if a local user holds the input device
open during a device unplug or driver unbind?
[ ... ]
> @@ -2900,6 +2901,14 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
> version);
>
> return 0;
> +
> +err_free_effect_ids:
> + kfree(data->effect_ids);
> +err_free_data:
> + kfree(data);
> +err_destroy_ff:
> + input_ff_destroy(dev);
[Severity: High]
Is it possible that calling input_ff_destroy(dev) here leaves a dangling
dev->flush pointer?
This frees dev->ff but does not clear the dev->flush = input_ff_flush
callback set earlier by input_ff_create().
Since hidpp_probe() ignores the initialization error, the input device
remains registered. If a userspace process opens and then closes the event
node, evdev_release() calls input_flush_device(), triggering
input_ff_flush():
guard(mutex)(&ff->mutex);
Does this cause a guaranteed NULL pointer dereference because dev->ff is now
NULL?
[Severity: High]
Additionally, since hidpp_ff_init() runs after hid_connect() has already
registered the device, it is visible to userspace.
If input_ff_create() succeeds, it sets the EV_FF bit. If a concurrent thread
immediately issues an EVIOCSFF ioctl, calling input_ff_upload() which uses
dev->ff, and this error path triggers simultaneously calling
input_ff_destroy(dev):
input_ff_destroy(dev);
Could this regression result in a use-after-free in the force-feedback ioctl
handler without any synchronization?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623065200.1966629-1-haoxiang_li2024@163.com?part=1
^ permalink raw reply related
* Re: [PATCH bpf-next v4 2/3] selftests/hid: Load only requested struct_ops maps
From: bot+bpf-ci @ 2026-06-23 7:02 UTC (permalink / raw)
To: chenyy23, jikos, bentiss, bpf, linux-input
Cc: chenyy23, shuah, ast, daniel, andrii, martin.lau, eddyz87, memxor,
song, yonghong.song, jolsa, linux-kselftest, linux-kernel, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260623062315.2694160-3-chenyy23@mails.tsinghua.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
> 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>
This looks like a fix for the auto-attach-only handling that left
struct_ops autocreate enabled, which was added by commit f64c1a459339
("selftests/hid: disable struct_ops auto-attach"). Should this include:
Fixes: f64c1a459339 ("selftests/hid: disable struct_ops auto-attach")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28007198717
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: Fix FF device cleanup on init failure
From: Haoxiang Li @ 2026-06-23 6:52 UTC (permalink / raw)
To: lains, hadess, jikos, bentiss, e.velds
Cc: linux-input, linux-kernel, Haoxiang Li
hidpp_ff_init() creates the input force-feedback device with
input_ff_create(), then allocates the HID++ FF private data,
effect ID array, and workqueue.
If any of those allocations fail after input_ff_create() succeeds,
the function returns an error without destroying the FF device.
Add an unwind path that frees the private allocations made by
hidpp_ff_init() and calls input_ff_destroy() for failures after
input_ff_create() succeeds.
Fixes: ff21a635dd1a ("HID: logitech-hidpp: Force feedback support for the Logitech G920")
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
drivers/hid/hid-logitech-hidpp.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 90b0184df777..fb2062233df2 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2861,18 +2861,19 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
* ownership to FF core
*/
data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
+ if (!data) {
+ error = -ENOMEM;
+ goto err_destroy_ff;
+ }
data->effect_ids = kzalloc_objs(int, num_slots);
if (!data->effect_ids) {
- kfree(data);
- return -ENOMEM;
+ error = -ENOMEM;
+ goto err_free_data;
}
data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
if (!data->wq) {
- kfree(data->effect_ids);
- kfree(data);
- return -ENOMEM;
+ error = -ENOMEM;
+ goto err_free_effect_ids;
}
data->hidpp = hidpp;
@@ -2902,6 +2903,14 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
version);
return 0;
+
+err_free_effect_ids:
+ kfree(data->effect_ids);
+err_free_data:
+ kfree(data);
+err_destroy_ff:
+ input_ff_destroy(dev);
+ return error;
}
/* ************************************************************************** */
--
2.25.1
^ permalink raw reply related
* [PATCH bpf-next v4 2/3] selftests/hid: Load only requested struct_ops maps
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
In-Reply-To: <20260623062315.2694160-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 v4 3/3] selftests/hid: Cover hid_bpf_get_data() size overflow
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
In-Reply-To: <20260623062315.2694160-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 callback records the helper result
without dereferencing any 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 96071b4800e82..2f423de831473 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 v4 1/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
In-Reply-To: <20260623062315.2694160-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 check_add_overflow() to reject wrapped range ends before comparing
the requested range end against ctx->allocated_size.
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 | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index d0130658091b0..536f6d01fd14c 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -17,6 +17,7 @@
#include <linux/kfifo.h>
#include <linux/minmax.h>
#include <linux/module.h>
+#include <linux/overflow.h>
#include "hid_bpf_dispatch.h"
const struct hid_ops *hid_ops;
@@ -296,10 +297,12 @@ __bpf_kfunc __u8 *
hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr_buf_size)
{
struct hid_bpf_ctx_kern *ctx_kern;
+ size_t end;
ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
- if (rdwr_buf_size + offset > ctx->allocated_size)
+ if (check_add_overflow(rdwr_buf_size, offset, &end) ||
+ end > ctx->allocated_size)
return NULL;
return ctx_kern->data + offset;
--
2.34.1
^ permalink raw reply related
* [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
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