Re: [PATCH] HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The input device is registered before its capabilities are fully initialized.
--

--- Patch [1]: [PATCH] HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler() ---
commit 4a13815d9787a8e4509f8221af788267db0c1886
Author: Ibrahim Hashimov <security@auditcode.ai>

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

This commit changes a bounds check in joycon_ctlr_read_handler() from
12 bytes to the full size of struct joycon_input_report. This prevents
an out-of-bounds read when decoding IMU reports that are smaller than
the full structure size.

> diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
> index e7302ec01ff1f..11b5fe05acf44 100644
> --- a/drivers/hid/hid-nintendo.c
> +++ b/drivers/hid/hid-nintendo.c
> @@ -2607,7 +2607,12 @@ static int joycon_ctlr_read_handler(struct joycon_ctlr *ctlr, u8 *data,
>  {
>  	if (data[0] == JC_INPUT_SUBCMD_REPLY || data[0] == JC_INPUT_IMU_DATA ||
>  	    data[0] == JC_INPUT_MCU_DATA) {
> -		if (size >= 12) /* make sure it contains the input report */
> +		/*
> +		 * The whole struct is cast and parsed below, including the
> +		 * IMU/subcmd union, not just the 12-byte partial header this
> +		 * used to check for.
> +		 */
> +		if (size >= sizeof(struct joycon_input_report))
>  			joycon_parse_report(ctlr,
>  					    (struct joycon_input_report *)data);
>  	}

While reviewing this file, I noticed a pre-existing issue in
joycon_input_create():

drivers/hid/hid-nintendo.c:joycon_input_create() {
[ ... ]
	ctlr->input->phys = hdev->phys;
	input_set_drvdata(ctlr->input, ctlr);

	ret = input_register_device(ctlr->input);
	if (ret)
		return ret;

	if (joycon_type_is_right_joycon(ctlr)) {
		joycon_config_right_stick(ctlr->input);
[ ... ]
}

[Severity: High]
This is a pre-existing issue, but is the input device registered here before
its capabilities are configured?

Calling input_register_device() before setting the keys and absolute axes
results in an empty capability map during registration. This causes the joydev
handler to reject the device since EV_KEY and EV_ABS are not set.

Could this lead to udev exporting empty capabilities, and evdev calculating
an incorrect event buffer size, causing applications to fail to reliably
recognize the controller?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715115253.91029-1-security@auditcode.ai?part=1