Message-ID: <8932507d2a35d26a1eca2eab2b35fd385d3570d9.camel@rong.moe>
Date: Thu, 08 May 2025 01:33:06 +0800
From: Rong Zhang <i@...g.moe>
To: Benjamin Tissoires <bentiss@...nel.org>
Cc: bugzilla-daemon@...nel.org, Jiri Kosina <jikos@...nel.org>, 
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org, Borislav Petkov
	 <bp@...en8.de>
Subject: Re: [Bug 220083] New: [REGRESSION, BISECTED] x86 ASM changes make
 dispatch_hid_bpf_output_report access not-present page

Hi Benjamin,

On Wed, 2025-05-07 at 19:03 +0800, Rong Zhang wrote:
> Hi Benjamin,
> 
> On Tue, 2025-05-06 at 17:35 +0200, Benjamin Tissoires wrote:
> > Hi Boris,
> > 
> > On May 06 2025, Borislav Petkov wrote:
> > > Switching to mail.
> > > 
> > > Hi Benjamin,
> > > 
> > > take a look at the below pls.
> > > 
> > > The RIP points to:
> > > 
> > >   22:   48 c1 e6 04             shl    $0x4,%rsi
> > >   26:   48 03 77 08             add    0x8(%rdi),%rsi
> > >   2a:*  65 48 ff 46 08          incq   %gs:0x8(%rsi)            <-- trapping instruction
> > >   2f:   c3                      ret
> > > 
> > > which really is a %gs-based access and the reporter has bisected this to
> > > 
> > >   9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets")
> > > 
> > > which looks related.
> > > 
> > > My silly guess would be some bpf program does per-cpu accesses but it doesn't
> > > know about this change so it tramples over registers. I mean, my fix would be
> > > to disable BPF but you young kids love to play with that...

[...]

> > However, the fact that this happens in an unplug event makes me think
> > that there may be a race here at play.
> > 
> > Another option is that I completely missed the use of srcu, but it was
> > working fine previously, so I have no ideas :)
> 
> Yes, this is weird.
> 
> I also tried uinput and some other HID devices (randomly borrowed from
> my friends). They all worked fine.
> 
> I have a Logitech Bolt receiver, too. Will find and try it out.

The good news is it always works fine.

> > Anyway, we need to wait for the reporter to tell us if there were any
> > HID-BPF program first because this will likely give us a hint on where
> > the issue is.
> 
> In another clean boot, I triggered the bug and dumped the hdev struct
> at fentry (fexit will never hit because of the PF) via bpftrace.

[...]

> See attachments for its output (warning: contains an extremely long
> line) and the decoded dmesg while tracing.
> 
> In another clean boot (again), I played around retsnoop to capture the
> Last Branch Records (type: any_return, ind_call) from
> dispatch_hid_bpf_output_report. This time I didn't trigger the issue,
> or else nothing would be captured due to the PF as mentioned above.
> Instead, I pressed Caps Lock on a keyboard under the same receiver
> several times to trigger hidinput_led_worker. I always got:
> 
> [#15] kprobe_multi_link_handler+0x5d      (kernel/trace/bpf_trace.c:2843)           ->  fprobe_entry+0xe6                   (kernel/trace/fprobe.c:321)
>                                                                                         . __fprobe_handler                  (kernel/trace/fprobe.c:224)
> [#14] fprobe_entry+0x21c                  (kernel/trace/fprobe.c:336)               ->  function_graph_enter_regs+0x15d     (kernel/trace/fgraph.c:676)
> [#13] function_graph_enter_regs+0x1cd     (kernel/trace/fgraph.c:718)               ->  ftrace_graph_func+0x3c              (arch/x86/kernel/ftrace.c:659)
> [#12] ftrace_graph_func+0x4c              (arch/x86/kernel/ftrace.c:661)            ->  ftrace_trampoline+0x83
> [#11] ftrace_trampoline+0xc2                                                        ->  dispatch_hid_bpf_output_report+0x9  (drivers/hid/bpf/hid_bpf_dispatch.c:120)
> [#10] __srcu_read_lock+0x20               (kernel/rcu/srcutree.c:757)               ->  dispatch_hid_bpf_output_report+0x73 (drivers/hid/bpf/hid_bpf_dispatch.c:133)
>                                                                                         . srcu_read_lock                    (include/linux/srcu.h:252)
> [#09] __srcu_read_unlock+0x1f             (kernel/rcu/srcutree.c:769)               ->  dispatch_hid_bpf_output_report+0xc5 (drivers/hid/bpf/hid_bpf_dispatch.c:148)
> [#08] dispatch_hid_bpf_output_report+0xe6 (drivers/hid/bpf/hid_bpf_dispatch.c:148)  ->  return_to_handler+0x0               (arch/x86/kernel/ftrace_64.S:358)
> 
> !    6us [0]  dispatch_hid_bpf_output_report
> 
> Thus, there is indeed no BPF program being called.

Since the Bolt receiver is mine, I also played around bpftrace and
retsnoop. Surprisingly, dispatch_hid_bpf_output_report was never called
when I unplugged the Bolt receiver or pressed Caps Lock on a keyboard
under it, but hidinput_led_worker was indeed called in both cases.

I am completely unfamiliar with HID stuff, so I traced
hidinput_get_led_field and revealed that hid->ll_driver->request was
pointed to usbhid_request, resulting in hidinput_led_worker returning
via a happy path. So the divergence is merely due to different driver
implementation.

This information may explain why the impact of the bug was limited to
certain types of devices. Besides, most Logitech Unifying receivers
reside on users' PCs and never been unplugged, so the bug can hardly be
triggered in their setup. In my case, I have a Unifying receiver
residing on a dock, so the first time I encountered the bug was when I
used the dock for a while and unplugged it (ouch!).

My rough guess is: the bug previously existed somewhere but had no
destructive effect. The per-cpu change isn't the bug itself, but turned
the bug to be destructive.

> Feel free to ask for more experiments :)
> 
> > Cheers,
> > Benjamin
> 
> Thanks,
> Rong
> 
> > > 
> > > :-)
> > > 
> > > Thx.
> > > 
> > > On Sat, May 03, 2025 at 06:40:41PM +0000, bugzilla-daemon@...nel.org wrote:
> > > 
> > > 

[...]

Thanks,
Rong

Powered by blists - more mailing lists