Re: [PATCH] HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad USB-C

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Unbounded recursion in `magicmouse_raw_event` when parsing malicious `DOUBLE_REPORT_ID` packets can cause a kernel stack overflow.
--

commit 58987e236bab550dc05b66346833ee21ed261110
Author: Andrei Fed <andfed.net@gmail.com>

HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad USB-C

This commit fixes battery reporting for the Bluetooth Magic Trackpad USB-C by
avoiding the misparsing query path. It introduces a battery quirk to skip the
query and instead fetches the battery at the end of the device probe.

> diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> index 802a3479e24b9..0c4e959322c3c 100644
> --- a/drivers/hid/hid-magicmouse.c
> +++ b/drivers/hid/hid-magicmouse.c

[ ... ]

[Severity: Critical]
This is a pre-existing issue, but while reviewing this file I noticed
that magicmouse_raw_event() doesn't seem to enforce a depth limit when
recursively calling itself to parse DOUBLE_REPORT_ID packets:

drivers/hid/hid-magicmouse.c:magicmouse_raw_event() {
    ...
	case DOUBLE_REPORT_ID:
		/* Sometimes the trackpad sends two touch reports in one
		 * packet.
		 */

		/* Ensure that we have at least 2 elements (report type and size) */
		if (size < 2)
			return 0;

		if (size < data[1] + 2) {
			hid_warn(hdev,
				 "received report length (%d) was smaller than specified (%d)",
				 size, data[1] + 2);
			return 0;
		}

		magicmouse_raw_event(hdev, report, data + 2, data[1]);
		magicmouse_raw_event(hdev, report, data + 2 + data[1],
			size - 2 - data[1]);
		return 0;
    ...
}

If a malicious Bluetooth or USB device sends a HID report starting with
DOUBLE_REPORT_ID (0xf7) and filled with the sequence [0xf7, 0x00], the inner
size byte data[1] evaluates to 0.

Could this cause magicmouse_raw_event() to recursively call itself with
size 0 (which returns immediately) and size - 2?

A 16KB malicious report could force ~8192 nested recursions, which might
overflow the standard kernel stack and lead to a denial of service panic.

Does this need an upper bound on recursion depth or an iterative approach
to prevent stack exhaustion?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706175507.47288-1-andfed.net@gmail.com?part=1