Re: [PATCH] HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()

On Tue, 14 Jul 2026, Jose Villaseñor Montfort wrote:

> magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack
> two touch reports into one, by splitting the packet and calling itself on
> each half. The only guard against runaway recursion is a "size < 1" check,
> which stops zero-sized calls but does not bound the recursion depth.
> 
> A malicious HID device that matches this driver can send a report starting
> with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level
> consumes two bytes and recurses on the remainder, so an incoming report of
> up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That
> easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a
> panic with CONFIG_VMAP_STACK, or memory corruption without it.
> 
> A double report only ever wraps two normal reports; it is never
> legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a
> recursive call so the recursion depth is bounded to two, while all valid
> packets keep being parsed exactly as before.
> 
> Fixes: a462230e16ac ("HID: magicmouse: enable Magic Trackpad support")
> Link: https://lore.kernel.org/linux-input/[email protected]/
> Cc: [email protected]
> Signed-off-by: Jose Villaseñor Montfort <[email protected]>
> ---
> Noticed while reviewing hid-magicmouse.c during the discussion of the
> parallel Magic Trackpad USB-C battery work [1]. The recursion issue is
> independent of that series and is sent as its own fix.
> 
> I also considered refactoring the report parsing into a non-recursive
> helper that dispatches the two sub-reports iteratively, which removes the
> recursion entirely. That is a larger and more intrusive change; this
> minimal guard keeps the diff small and is trivial to backport, so I went
> with it. Happy to switch to the refactor if maintainers prefer it.

Looks good to me, thanks. Queued.

-- 
Jiri Kosina
SUSE Labs