CVE-2026-80772 in Linuxinfo

Summary

by MITRE • 09/04/2026

In the Linux kernel, the following vulnerability has been resolved:

HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()

joycon_ctlr_read_handler() casts an incoming HID input report to struct joycon_input_report and parses it, guarding the cast only with a 12-byte length check:

if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data);

struct joycon_input_report is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report() -> joycon_parse_imu_report() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA 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 joycon_ctlr_handle_event() already bounds the same cast correctly:

if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY)
break;

Use the same sizeof(struct joycon_input_report) bound here.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 09/04/2026

The Linux kernel HID Nintendo driver contains a critical out-of-bounds read vulnerability within the joycon_ctlr_read_handler function, which processes input reports from connected Joy-Con or Pro Controllers. This flaw arises from an insufficient length validation check that fails to account for the actual size of the data structure being parsed. Specifically, the handler casts incoming raw HID input report data into a struct joycon_input_report without verifying that the buffer contains enough bytes to safely access all fields within that structure. The existing guard only checks if the reported size is greater than or equal to twelve bytes, which corresponds merely to the header portion of the report rather than the full structure required for subsequent parsing operations.

The structural definition of struct joycon_input_report reveals a significant discrepancy between the validation threshold and the actual memory requirements. This structure consists of a thirteen-byte header followed by a union that includes an IMU arm field spanning thirty-six bytes, resulting in a total size of forty-nine bytes. When the driver processes an input report identified as containing IMU data, it invokes joycon_parse_report which subsequently calls joycon_parse_imu_report to decode sensor values such as accelerometer and gyroscope readings. This parsing routine iterates through offsets ranging from thirteen to forty-eight within the union structure. Consequently, if a malicious or spoofed controller sends a report with exactly twelve bytes of payload data but sets the first byte to indicate IMU input type, the initial check passes despite the buffer being severely undersized for the intended operation.

This logic error leads to an out-of-bounds read where the driver accesses up to thirty-seven bytes beyond the declared length of the incoming packet. Although the receive buffers are allocated with a size matching the maximum possible report length, meaning this is technically an over-read within the same allocation rather than a slab-based buffer overflow, the security implications remain severe. The uninitialized or stale memory contents located at these out-of-bounds offsets are decoded as valid sensor data and subsequently forwarded to user space through the IMU input device interface. This mechanism effectively allows a local attacker with access to HID devices to leak driver-internal kernel memory into userspace applications, potentially exposing sensitive information such as stack canaries, pointers, or other confidential kernel state that resides in adjacent memory regions.

The vulnerability is classified under CWE-125, which describes out-of-bounds read vulnerabilities where software reads data past the end of a buffer or array. In terms of attack vectors and techniques, this flaw aligns with ATT&CK technique T1083, specifically related to file and directory discovery through memory inspection if such leaks facilitate further exploitation steps like information gathering for privilege escalation. The root cause is identified as CWE-20, indicating improper input validation where the software does not sufficiently verify that supplied inputs meet specified requirements before processing them. This stands in stark contrast to the sibling subcommand handling path within joycon_ctlr_handle_event, which correctly validates buffer sizes against sizeof(struct joycon_input_report) before casting and parsing data, highlighting an inconsistency in defensive coding practices across similar code paths.

To mitigate this vulnerability, developers must enforce strict bounds checking that aligns with the actual size of the target structure rather than arbitrary minimum thresholds. The fix involves replacing the twelve-byte length check with a validation against sizeof(struct joycon_input_report), ensuring that any report claiming to contain IMU data actually provides sufficient payload bytes to safely populate all fields within the union. This adjustment prevents the driver from accessing memory beyond the allocated packet boundaries and stops the leakage of kernel internals to user space. System administrators should apply the corresponding kernel patch or update their distribution packages immediately, as this issue affects systems utilizing Nintendo HID controllers with active IMU reporting features. Regular auditing of input validation logic in device drivers is recommended to prevent similar discrepancies between declared structure sizes and enforced buffer limits from recurring in other subsystems.

Responsible

Linux

Reservation

08/26/2026

Disclosure

09/04/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!