PT-2026-85623 · Linux · Linux
CVE-2026-80782
·
Publicado
2026-09-04
·
Atualizado
2026-09-04
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
In the Linux kernel, the following vulnerability has been resolved:
HID: magicmouse: do not keep a stale msc->input if no input is claimed
magicmouse input mapping() caches the first hid input's input dev in
msc->input while the report descriptor is parsed, and the rest of the
driver treats a non-NULL msc->input as proof that an input device was
registered.
That does not hold on the hid-input error path. If hidinput connect()
fails -- for instance because input register device() returns an error --
it unwinds through hidinput disconnect(), which frees every input dev it
created, including the one cached in msc->input.
The failure does not abort the probe. hid connect() only skips the claim:
if ((connect mask & HID CONNECT HIDINPUT) && !hidinput connect(hdev,
connect mask & HID CONNECT HIDINPUT FORCE))
hdev->claimed |= HID CLAIMED INPUT;and the "device has no listeners" bailout below it does not fire for this
driver, which sets ->raw event; on the USB Magic Mouse 2 / Magic Trackpad
2 paths hidraw and hiddev are claimed as well. hid hw start() therefore
returns 0 and magicmouse probe() continues with msc->input pointing at
freed memory. Being non-NULL, it passes the "input not registered" check
in probe and the NULL checks in ->raw event and ->event, so the next
input report dereferences freed memory.
Clear msc->input when the HID core did not claim an input device, so the
existing NULL checks cover this case as well.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux