Re: [PATCH] HID: hidraw: fix use-after-free and double free on disconnect

[Chad Aldreda <ca@modelmiser.com>]

On Sun, 11 Oct 2026, Jinmo Yang wrote:
> hidraw_report_event() dereferences hid->hidraw with nothing keeping the
> object alive, and hidraw_disconnect() frees it without clearing the
> pointer:

Tested on mainline d48723711bae (v7.4-rc1-672), on x86_64 in QEMU (4
vCPUs) with KASAN, lockdep, DEBUG_LIST and kmemleak, and without a
window-widening patch. A test program creates two uhid devices with the
Wacom vendor ID that bind hid-wacom as generic pen and touch siblings.
The pen device's descriptor has the WACOM_HID_WD_MODE_CHANGE usage, so a
report that toggles it schedules wacom_mode_change_work(), which stops
and restarts both devices.

Without the patch, toggling that bit about every 2 ms for 20 s (about
9,400 reports, nothing else sent) gave slab-use-after-free reports
reached from hidraw_report_event() in every run (5 of 5; 31 to 61 KASAN
reports per run, which looks like 2 to 4 hits of about 15 reports each),
on an object freed by hidraw_disconnect() <- hid_disconnect() <-
hid_hw_stop() <- wacom_mode_change_work(). The free path matches your
trace, and it reproduces without any window-widening delay.

With the patch, 11 runs of the same (220 s in all) had no KASAN, lockdep
or DEBUG_LIST reports. kmemleak listed unreferenced objects after 2 of
those 11 runs, and after 3 of the 4 unpatched runs that got as far as
the scan; I have not looked at what they are. About 18 million pen and
touch reports over 20 s without any mode changes gave no KASAN, lockdep
or DEBUG_LIST reports with or without the patch.

Sending pen and touch reports while the mode is toggling oopses the
kernel within seconds with or without the patch. In every such run the
first fault is the same NULL pointer dereference in wacom_wac_event(),
called from wacom_wac_report(), and the later reports are on a tainted
kernel. That is in hid-wacom, in a function your v4 NULL-input series
does not change, and after it those runs say nothing about hidraw.

Not tested: the double-free hunk (I never saw two teardowns of the same
device overlap), the NULL check on its own without the RCU change,
reading an open hidraw node during teardown (attempted, but the
hid-wacom fault above comes first), transports that deliver reports from
interrupt context, real hardware, arm64, and module unload (everything
was built in).

The harness and this report were produced with an AI assistant (Claude
Opus 5.5), which also did the earlier runs, including the unpatched
comparison. I ran the final version on the patched kernel myself and got
the same results. The harness is available on request.

Tested-by: Chad Aldreda <ca@modelmiser.com>