CVE-2026-80772: HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()
In the Linux kernel, the following vulnerability has been resolved:
HID: nintendo: fix out-of-bounds read in joyconctlrreadhandler()
joyconctlrreadhandler() casts an incoming HID input report to struct joyconinputreport and parses it, guarding the cast only with a 12-byte length check:
if (size >= 12) / make sure it contains the input report / joyconparsereport(ctlr, (struct joyconinputreport )data);
struct joyconinputreport is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joyconparsereport() -> joyconparseimureport() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JCINPUTIMUDATA passes the guard yet is read up to 37 bytes past its declared length. The over-read bytes are decoded into accelerometer/gyroscope values and forwarded to userspace through the "(IMU)" input device, leaking driver-internal memory. data[0] and size are fully controlled by a malicious or spoofed Joy-Con/Pro Controller.
Receive buffers are sized to the maximum report length, so this is an over-read within the allocation rather than a slab OOB, but the decoded bytes still reach userspace.
The sibling subcmd path in joyconctlrhandleevent() already bounds the same cast correctly:
if (size < sizeof(struct joyconinputreport) || data[0] != JCINPUTSUBCMDREPLY) break;
Use the same sizeof(struct joyconinputreport) bound here.
Affected Software
Event History
Frequently Asked Questions
What must an attacker control to trigger the issue?
An attacker needs to provide HID input reports through a malicious or spoofed Joy-Con or Pro Controller. They control both the report type byte and the reported length; an IMU report with a declared length of 12 bytes can trigger the over-read.
What information can be exposed if the issue is triggered?
Bytes beyond the report's declared length are interpreted as accelerometer and gyroscope data and forwarded to userspace through the controller's "(IMU)" input device. This can disclose driver-internal memory contents to userspace.
Does this read extend beyond the receive-buffer allocation?
No. The receive buffers are sized for the maximum report length, so the read remains within the allocated buffer. However, it still reads data beyond the supplied report length and exposes decoded contents to userspace.