From: "Shengzhuo Wei" <me@cherr.cc>
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Derek John Clark" <derekjohn.clark@gmail.com>
Cc: "Shengzhuo Wei" <me@cherr.cc>, "Jiri Kosina" <jikos@kernel.org>,
"Benjamin Tissoires" <bentiss@kernel.org>,
"Zhouwang Huang" <honjow311@gmail.com>,
<linux-input@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<stable@vger.kernel.org>
Subject: Re: [PATCH v2] HID: hid-oxp: fix UAF on pending work in remove()
Date: Wed, 5 Aug 2026 16:01:12 +0800 [thread overview]
Message-ID: <anLtyBB-Vq2D6REw@pve> (raw)
In-Reply-To: <anK_oQqFpZLwCA-a@google.com>
Hi Derek, Dmitry,
Derek wrote:
> Out of curiosity, do you have a device available to test as well? If
> so, which model do you have?
I don't have any OneXPlayer hardware. I found this bug by creating a
gen2 OXP device through /dev/uhid and tearing it down under KASAN in
QEMU, not on a real device, and I'm not deeply familiar with the HID
subsystem overall.
On disable_delayed_work_sync() I seem to be caught between your two
positions. Derek:
> I don't think the bug fix switching to disable_delayed_work_sync is
> worth the side effects without first addressing the global drvdata
> issue. That would introduce a true regression to fix a theoretical
> logic bug. I would rather you either switch to the devm_alloc drvdata
> first or hold that change until I'm able to do it later myself.
Dmitry:
> If there is possibility to have multiple instances then this driver is
> FUBAR in the current shape: one device instance fires up work items
> for another device. So holding the patch makes no sense IMO.
I'm not well placed to own the per-device drvdata refactor: I have no
hardware to validate the multi-interface behavior, and I don't have the
HID-subsystem familiarity to do that rework confidently. So I'd rather
not take that piece on.
Given that, what would you like me to do? The realistic contribution I
can stand behind is a minimal v3 that only fixes the use-after-free I
actually found and verified -- cancel_delayed_work() ->
cancel_delayed_work_sync() in oxp_hid_remove() (the v1 approach),
reverting v2's probe change and dropping disable_delayed_work_sync().
It's KASAN-verified, introduces no regression, and needs no hardware.
The re-arm hardening and the drvdata/attr-ordering rework would then be
Derek's, on real hardware with the hid-msi pattern.
If you'd rather I drop the patch entirely and leave the whole thing
(including the cancel_delayed_work_sync part) to Derek, that's fine
too. I'd like to land this fix if there's a version of it you'd accept
from me, but I defer to your judgment on scope -- I just didn't want to
silently walk away from a bug I reported.
Thanks,
Shengzhuo
prev parent reply other threads:[~2026-08-05 8:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 9:50 Shengzhuo Wei
2026-08-04 20:06 ` Shengzhuo Wei
2026-08-04 21:24 ` Derek John Clark
2026-08-05 4:53 ` Dmitry Torokhov
2026-08-05 8:01 ` Shengzhuo Wei [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anLtyBB-Vq2D6REw@pve \
--to=me@cherr.cc \
--cc=bentiss@kernel.org \
--cc=derekjohn.clark@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=honjow311@gmail.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®