From: "Jose Villaseñor Montfort" <pepemontfort@gmail.com>
To: Jiri Kosina <jikos@kernel.org>, Benjamin Tissoires <bentiss@kernel.org>
Cc: "Alec Hall" <signshop.alec@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
"Jose Villaseñor Montfort" <pepemontfort@gmail.com>
Subject: [PATCH v2] HID: magicmouse: avoid NULL pointer deref when there is no input device
Date: Tue, 28 Jul 2026 12:40:59 -0600 [thread overview]
Message-ID: <20260728184059.688513-1-pepemontfort@gmail.com> (raw)
In-Reply-To: <20260715195853.1302765-1-pepemontfort@gmail.com>
magicmouse_raw_event() and magicmouse_event() dereference msc->input
(e.g. input->id.product, and via magicmouse_emit_touch() and
magicmouse_emit_buttons()) without checking it for NULL. hid-input only
sets msc->input when the device exposes a usable input device.
magicmouse_probe() has an "input not registered" check that fails the
probe when msc->input is NULL, but the USB Magic Mouse 2 / Magic
Trackpad 2 path returns 0 before reaching it. Real hardware ends up in
that state: a USB Magic Trackpad 2 exposes four HID interfaces and only
the first two register an input, and a USB-C Magic Trackpad (05ac:0324)
exposes three with the same split. The remaining interfaces are
vendor-defined, are claimed as hiddev/hidraw only, and stay bound to
this driver with msc->input == NULL.
Both callbacks are reachable in that state. ->raw_event is called for
every incoming report, and hid_process_event() calls ->event without
requiring HID_CLAIMED_INPUT -- hid_match_usage() matches everything here
because this driver has no usage_table. An input report on one of those
interfaces therefore dereferences a NULL pointer and panics the kernel.
A device that binds this driver by spoofing an Apple VID/PID, with a
report descriptor that does not produce an input device, reaches the
same state.
Bail out of both callbacks when msc->input is NULL and leave the report
to the generic HID paths, which is what those interfaces get today.
Rejecting the bind in magicmouse_probe() instead would unbind interfaces
that a healthy device legitimately exposes and drop their hidraw nodes.
Fixes: 0b91b4e4dae6 ("HID: magicmouse: Report battery level over USB")
Suggested-by: Alec Hall <signshop.alec@gmail.com>
Link: https://lore.kernel.org/linux-input/20260714102540.3EB2E1F000E9@smtp.kernel.org/
Link: https://lore.kernel.org/linux-input/20260728072554.47069-1-signshop.alec@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Jose Villaseñor Montfort <pepemontfort@gmail.com>
---
Changes in v2:
- Switch from rejecting the bind in magicmouse_probe() to guarding both
callbacks. Alec Hall tested v1 on a USB Magic Trackpad 2 and found that
it unbinds interfaces 2 and 3: they are vendor-defined, have no input
device, and have been claimed by this driver since 0b91b4e4dae6, so
every cable plug logged two -ENOMEM probe failures and their hidraw
nodes went away. Nothing user-facing broke (touch and battery live on
interfaces 0/1), but silently unbinding a healthy device's interfaces
is not a change to make in a stable-tagged fix. Report:
https://lore.kernel.org/linux-input/20260728072554.47069-1-signshop.alec@gmail.com/
- I confirmed the same shape on a USB-C Magic Trackpad (05ac:0324) here,
on an unpatched 7.1.5: three HID interfaces, all three bound to
magicmouse, and the last one -- vendor-defined, bInterfaceSubClass 0,
two endpoints -- has a hidraw node but no input device. So the exact
interface count varies by model, but at least one input-less interface
bound to this driver is normal on genuine hardware.
- Reworded the commit message accordingly. Those interfaces show that a
bind with msc->input == NULL is a state real hardware reaches, not only
a spoofed device; and hid_process_event() calls ->event regardless of
HID_CLAIMED_INPUT (hid_match_usage() matches everything, this driver
has no usage_table), so ->event is reachable on them too.
- v1: https://lore.kernel.org/linux-input/20260715195853.1302765-1-pepemontfort@gmail.com/
This is a sibling hardening fix to "HID: magicmouse: prevent unbounded
recursion in magicmouse_raw_event()" [1], which touches the same driver.
If that one is applied first, this needs a trivial rebase: the guard
moves into __magicmouse_raw_event().
[1] https://lore.kernel.org/linux-input/20260715053526.574725-1-pepemontfort@gmail.com/
drivers/hid/hid-magicmouse.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index 802a3479e..7164ced59 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -390,6 +390,14 @@ static int magicmouse_raw_event(struct hid_device *hdev,
struct input_dev *input = msc->input;
int x = 0, y = 0, ii, clicks = 0, npoints;
+ /*
+ * This driver also binds interfaces that hid-input does not create an
+ * input device for, so msc->input can legitimately be NULL here. Leave
+ * their reports to the generic HID paths instead of dereferencing it.
+ */
+ if (!input)
+ return 0;
+
/* Protect against zero sized recursive calls from DOUBLE_REPORT_ID */
if (size < 1)
return 0;
@@ -538,6 +546,11 @@ static int magicmouse_event(struct hid_device *hdev, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
struct magicmouse_sc *msc = hid_get_drvdata(hdev);
+
+ /* See the comment in magicmouse_raw_event(). */
+ if (!msc->input)
+ return 0;
+
if ((msc->input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE2 ||
msc->input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE2_USBC) &&
field->report->id == MOUSE2_REPORT_ID) {
base-commit: b7556c8e713c88596046a906c7c4385218d44736
--
2.55.0
next prev parent reply other threads:[~2026-07-28 18:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 19:58 [PATCH] HID: magicmouse: reject devices that bind without an " Jose Villaseñor Montfort
2026-07-28 7:25 ` Alec Hall
2026-07-28 18:37 ` Jose Villaseñor Montfort
2026-07-28 18:40 ` Jose Villaseñor Montfort [this message]
[not found] ` <20260728185542.65F091F000E9@smtp.kernel.org>
2026-07-29 4:07 ` [PATCH v2] HID: magicmouse: avoid NULL pointer deref when there is no " Jose Villaseñor Montfort
2026-08-03 3:37 ` Alec Hall
2026-08-04 2:50 ` Jose Villaseñor Montfort
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=20260728184059.688513-1-pepemontfort@gmail.com \
--to=pepemontfort@gmail.com \
--cc=bentiss@kernel.org \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=signshop.alec@gmail.com \
/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®