* [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
@ 2026-04-24 10:22 Zhao Mengmeng
2026-04-24 11:16 ` sashiko-bot
2026-04-24 13:53 ` Alexei Starovoitov
0 siblings, 2 replies; 5+ messages in thread
From: Zhao Mengmeng @ 2026-04-24 10:22 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, bpf, Zhao Mengmeng
From: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
Pahole intersects flags across BTF_ID_FLAGS() occurrences, so omitting
KF_SLEEPABLE may drops the flags globally. sync this flags in
hid_bpf_syscall_kfuncs set to enforce consistency and safety.
Link: https://lore.kernel.org/sched-ext/177693500312.275653.17323765149266875001.b4-reply@b4/
Signed-off-by: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index 50c7b45c59e3..62db80ead86e 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -585,11 +585,11 @@ static const struct btf_kfunc_id_set hid_bpf_kfunc_set = {
/* for syscall HID-BPF */
BTF_KFUNCS_START(hid_bpf_syscall_kfunc_ids)
-BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL)
-BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE)
-BTF_ID_FLAGS(func, hid_bpf_hw_request)
-BTF_ID_FLAGS(func, hid_bpf_hw_output_report)
-BTF_ID_FLAGS(func, hid_bpf_input_report)
+BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL | KF_SLEEPABLE)
+BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE | KF_SLEEPABLE)
+BTF_ID_FLAGS(func, hid_bpf_hw_request, KF_SLEEPABLE)
+BTF_ID_FLAGS(func, hid_bpf_hw_output_report, KF_SLEEPABLE)
+BTF_ID_FLAGS(func, hid_bpf_input_report, KF_SLEEPABLE)
BTF_KFUNCS_END(hid_bpf_syscall_kfunc_ids)
static const struct btf_kfunc_id_set hid_bpf_syscall_kfunc_set = {
---
base-commit: a67bb21a5fc478443d6db490c7049e9aeeb92bd4
change-id: 20260424-btf-define-622697aaece1
Best regards,
--
Zhao Mengmeng <zhaomengmeng@kylinos.cn>
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
2026-04-24 10:22 [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set Zhao Mengmeng
@ 2026-04-24 11:16 ` sashiko-bot
2026-04-24 13:53 ` Alexei Starovoitov
1 sibling, 0 replies; 5+ messages in thread
From: sashiko-bot @ 2026-04-24 11:16 UTC (permalink / raw)
To: Zhao Mengmeng; +Cc: bpf
Sashiko AI review found 2 potential issue(s):
- [Critical] ZERO_SIZE_PTR dereference in hid_bpf_hw_request() causes a kernel panic.
- [High] Integer promotion bug in hid_bpf_hw_request() silently masks hardware failures.
--
commit 5998989ac7e53dfd091520e5a1a9f8e928c8cf45
Author: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
This commit synchronizes the KF_SLEEPABLE flag for syscall HID-BPF functions
in the hid_bpf_syscall_kfuncs set. This prevents the flag from being
inadvertently dropped globally when pahole intersects flags across BTF IDs.
Link: https://lore.kernel.org/sched-ext/177693500312.275653.17323765149266875001.b4-reply@b4/
> diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
> index 50c7b45c59e3fb..62db80ead86e51 100644
> --- a/drivers/hid/bpf/hid_bpf_dispatch.c
> +++ b/drivers/hid/bpf/hid_bpf_dispatch.c
> @@ -585,11 +585,11 @@ static const struct btf_kfunc_id_set hid_bpf_kfunc_set = {
>
> /* for syscall HID-BPF */
> BTF_KFUNCS_START(hid_bpf_syscall_kfunc_ids)
> -BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL)
> -BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE)
> -BTF_ID_FLAGS(func, hid_bpf_hw_request)
This isn't a bug in this commit, but since the BTF flags are being updated
for hid_bpf_hw_request(), I noticed a potential issue in that function.
Can a ZERO_SIZE_PTR dereference occur if a HID device has an empty report?
When a BPF program invokes hid_bpf_hw_request() with buf__sz >= 1, and the
device has no fields and no report ID, hid_report_len() can return 0:
drivers/hid/bpf/hid_bpf_dispatch.c:__hid_bpf_hw_check_params() {
...
report_len = hid_report_len(report);
if (*buf__sz > report_len)
*buf__sz = report_len;
...
}
This clamps the size to 0. Back in hid_bpf_hw_request(), this 0 size
is passed to kmemdup():
drivers/hid/bpf/hid_bpf_dispatch.c:hid_bpf_hw_request() {
...
dma_data = kmemdup(buf, size, GFP_KERNEL);
if (!dma_data)
return -ENOMEM;
ret = hid_ops->hid_hw_raw_request(ctx->hid,
dma_data[0],
...
}
For 0-byte allocations, the slab allocator returns ZERO_SIZE_PTR (0x10),
not NULL. The !dma_data check will pass, and the function will dereference
dma_data[0], potentially causing a panic.
Additionally, can negative error codes from hid_hw_raw_request() be
permanently masked?
The variable ret is an int, while size is a size_t. When hid_hw_raw_request()
fails, it returns a negative error code (e.g., -EIO).
drivers/hid/bpf/hid_bpf_dispatch.c:hid_bpf_hw_request() {
...
int ret;
size_t size = buf__sz;
...
ret = hid_ops->hid_hw_raw_request(...);
if (ret > size)
ret = size;
...
}
Due to C integer promotion rules, the signed int ret is cast to an unsigned
size_t before comparison. Any negative error code is converted to a large
positive integer, causing ret > size to evaluate to true. The function then
executes the ret = size assignment, masking the hardware failure.
> -BTF_ID_FLAGS(func, hid_bpf_hw_output_report)
> -BTF_ID_FLAGS(func, hid_bpf_input_report)
> +BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL | KF_SLEEPABLE)
> +BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE | KF_SLEEPABLE)
> +BTF_ID_FLAGS(func, hid_bpf_hw_request, KF_SLEEPABLE)
> +BTF_ID_FLAGS(func, hid_bpf_hw_output_report, KF_SLEEPABLE)
> +BTF_ID_FLAGS(func, hid_bpf_input_report, KF_SLEEPABLE)
> BTF_KFUNCS_END(hid_bpf_syscall_kfunc_ids)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260424-btf-define-v1-1-0f52dffad5aa@kylinos.cn?part=1
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
2026-04-24 10:22 [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set Zhao Mengmeng
2026-04-24 11:16 ` sashiko-bot
@ 2026-04-24 13:53 ` Alexei Starovoitov
2026-04-24 14:54 ` Benjamin Tissoires
1 sibling, 1 reply; 5+ messages in thread
From: Alexei Starovoitov @ 2026-04-24 13:53 UTC (permalink / raw)
To: Zhao Mengmeng, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, bpf, Zhao Mengmeng
On Fri Apr 24, 2026 at 3:22 AM PDT, Zhao Mengmeng wrote:
> From: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
>
> Pahole intersects flags across BTF_ID_FLAGS() occurrences, so omitting
> KF_SLEEPABLE may drops the flags globally. sync this flags in
> hid_bpf_syscall_kfuncs set to enforce consistency and safety.
Makes no sense.
These kfuncs are not sleepable.
pw-bot: cr
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
2026-04-24 13:53 ` Alexei Starovoitov
@ 2026-04-24 14:54 ` Benjamin Tissoires
2026-04-24 15:50 ` Zhao mengmeng
0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Tissoires @ 2026-04-24 14:54 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Zhao Mengmeng, Jiri Kosina, linux-input, linux-kernel, bpf,
Zhao Mengmeng
On Apr 24 2026, Alexei Starovoitov wrote:
> On Fri Apr 24, 2026 at 3:22 AM PDT, Zhao Mengmeng wrote:
> > From: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
> >
> > Pahole intersects flags across BTF_ID_FLAGS() occurrences, so omitting
> > KF_SLEEPABLE may drops the flags globally. sync this flags in
> > hid_bpf_syscall_kfuncs set to enforce consistency and safety.
>
> Makes no sense.
> These kfuncs are not sleepable.
I'm not sure I parse correctly the reason for the dropping of the flags
by pahole, but all of those kfuncs are actually sleepable, except for
hid_bpf_input_report, which is *not* sleepable.
Cheers,
Benjamin
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
2026-04-24 14:54 ` Benjamin Tissoires
@ 2026-04-24 15:50 ` Zhao mengmeng
0 siblings, 0 replies; 5+ messages in thread
From: Zhao mengmeng @ 2026-04-24 15:50 UTC (permalink / raw)
To: Benjamin Tissoires, Alexei Starovoitov
Cc: Jiri Kosina, linux-input, linux-kernel, bpf, Zhao Mengmeng
On April 24, 2026 10:54:45 PM GMT+08:00, Benjamin Tissoires <bentiss@kernel.org> wrote:
>On Apr 24 2026, Alexei Starovoitov wrote:
>> On Fri Apr 24, 2026 at 3:22 AM PDT, Zhao Mengmeng wrote:
>> > From: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
>> >
>> > Pahole intersects flags across BTF_ID_FLAGS() occurrences, so omitting
>> > KF_SLEEPABLE may drops the flags globally. sync this flags in
>> > hid_bpf_syscall_kfuncs set to enforce consistency and safety.
>>
>> Makes no sense.
>> These kfuncs are not sleepable.
>
>I'm not sure I parse correctly the reason for the dropping of the flags
>by pahole, but all of those kfuncs are actually sleepable, except for
>hid_bpf_input_report, which is *not* sleepable.
>
>Cheers,
>Benjamin
Hi Benjamin,
Sorry for the noise. I misunderstood the difference between KF_SLEEPABLE
and other KF_XX flags. The initial reason to send the patch is l found a
function signature change after a kfunc in two kfuncs sets, one with KF_IMPLICIT_ARGS,
while the other one without it. So I naively think that all kfuncs should
keep consistant declaration. Alexei is right, l will do more background work
before sending patches next time.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-04-24 15:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-24 10:22 [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set Zhao Mengmeng
2026-04-24 11:16 ` sashiko-bot
2026-04-24 13:53 ` Alexei Starovoitov
2026-04-24 14:54 ` Benjamin Tissoires
2026-04-24 15:50 ` Zhao mengmeng
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.