Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Dangling pointer in `drvdata->input` leads to Use-After-Free if `hidinput_connect()` fails during device probe.
--

--- Patch [1]: [PATCH] HID: add driver for Gigabyte Aero vendor-specific brightness keys ---

commit 1b9632575a5f9cf3b6d4d94e30945e582cc34a94
Author: Uddhav Swami [off-list ref]

    HID: add driver for Gigabyte Aero vendor-specific brightness keys

This commit adds a minimal HID driver that intercepts vendor-defined HID
reports for the Gigabyte Aero 15 XB keyboard. It maps values 0x7D and 0x7E
to KEY_BRIGHTNESSDOWN and KEY_BRIGHTNESSUP respectively.

[ ... ]

+static int gigabyte_aero_input_configured(struct hid_device *hdev,
+					  struct hid_input *hi)
+{
+	struct gigabyte_drvdata *drvdata = hid_get_drvdata(hdev);
+	struct input_dev *input = hi->input;
+
+	input_set_capability(input, EV_KEY, KEY_BRIGHTNESSUP);
+	input_set_capability(input, EV_KEY, KEY_BRIGHTNESSDOWN);
+
+	drvdata->input = input;

[Severity: High]
Can drvdata->input become a dangling pointer here if input registration fails?

If hidinput_connect() fails later during the probe sequence (for example, if
input_register_device() fails), hidinput_disconnect() will be called and it
frees the input_dev.

However, because this driver implements a .raw_event callback, hid_connect()
will still return success. This allows hid_hw_start() to return 0 and the
probe to complete successfully.

If that happens, drvdata->input is left pointing to the freed input_dev,
which will trigger a use-after-free in gigabyte_aero_raw_event() when a
brightness key is pressed:

	case GIGABYTE_AERO_BRIGHTNESS_DOWN:
		input_report_key(drvdata->input, KEY_BRIGHTNESSDOWN, 1);

Could we avoid this by checking if (hdev->claimed & HID_CLAIMED_INPUT) is
set after hid_hw_start() completes in gigabyte_aero_probe()?

+
+	return 0;
+}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715004457.100650-1-uddhavswami@gmail.com?part=1