[PATCH 0/7] ASUS Zenbook Duo keyboard support

[PATCH 0/7] ASUS Zenbook Duo keyboard support

[Paolo Pisati]

Add support for the ASUS Zenbook Duo line of usb/BT wireless convertible keyboards.

This patchset is a collective effort, gathered here:

https://github.com/NeroReflex/asusctl/issues/25

Tested by many on all Zenbook Duo SKUs: UX8406MA, UX8406CA and UX8407AA.

Joshua Leivenzon (6):
  hid-asus: Fix up Zenbook Duo report descriptors
  hid-asus: Add missing Zenbook Duo hotkeys
  hid-asus: Add report descriptor fixup offsets for UX8406MA USB
    keyboard
  hid-asus: Remove more bogus zero bytes from some report descriptors
  hid-asus: Fix input mapping on dedicated vendor HID interfaces
  hid-asus: Allow adding custom hotkey handler logic

Luke Jones (1):
  hid-asus: add prod-id, quirk for Zenbook Duo keyboard

 drivers/hid/hid-asus.c | 126 +++++++++++++++++++++++++++++++++++++----
 drivers/hid/hid-ids.h  |   6 ++
 2 files changed, 121 insertions(+), 11 deletions(-)

-- 
2.53.0

[PATCH 1/7] hid-asus: Fix up Zenbook Duo report descriptors

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

This is similar to the T100CHI/T90CHI keyboard dock fix.
Without it, all reports log:

Unmapped Asus vendor usagepage code 0x76

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
---
 drivers/hid/hid-asus.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 3f5e96900b67a..ce246efba74d3 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -99,6 +99,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
 #define QUIRK_ROG_CLAYMORE_II_KEYBOARD	BIT(12)
 #define QUIRK_ROG_ALLY_XPAD		BIT(13)
 #define QUIRK_HID_FN_LOCK		BIT(14)
+#define QUIRK_ZENBOOK_DUO_KEYBOARD	BIT(15)
 
 #define I2C_KEYBOARD_QUIRKS			(QUIRK_FIX_NOTEBOOK_REPORT | \
 						 QUIRK_NO_INIT_REPORTS | \
@@ -1384,17 +1385,20 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		hid_info(hdev, "Fixing up Asus T100 keyb report descriptor\n");
 		rdesc[74] &= ~HID_MAIN_ITEM_CONSTANT;
 	}
-	/* For the T100CHI/T90CHI keyboard dock */
-	if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI)) {
+	/* For the T100CHI/T90CHI keyboard dock and Zenbook Duo 2024+ keyboards */
+	if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI | QUIRK_ZENBOOK_DUO_KEYBOARD)) {
 		int rsize_orig;
 		int offs;
 
 		if (drvdata->quirks & QUIRK_T100CHI) {
 			rsize_orig = 403;
 			offs = 388;
-		} else {
+		} else if (drvdata->quirks & QUIRK_T90CHI) {
 			rsize_orig = 306;
 			offs = 291;
+		} else if (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) {
+			rsize_orig = 257;
+			offs = 176;
 		}
 
 		/*
@@ -1414,7 +1418,8 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 
 			hid_info(hdev, "Fixing up %s keyb report descriptor\n",
 				drvdata->quirks & QUIRK_T100CHI ?
-				"T100CHI" : "T90CHI");
+				"T100CHI" : drvdata->quirks & QUIRK_T90CHI ?
+				"T90CHI" : "ZENBOOK DUO");
 
 			memcpy(new_rdesc, rdesc, rsize_orig);
 			*rsize = rsize_orig + 1;
-- 
2.53.0

Re: [PATCH 1/7] hid-asus: Fix up Zenbook Duo report descriptors

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The report descriptor fixup for the Zenbook Duo corrupts the descriptor because it incorrectly shifts only 12 bytes and allocates insufficient memory.
--

commit 6124d2bbfc4e5254d102730c30ac761f188e21b0
Author: Joshua Leivenzon <hacker1024@users.sourceforge.net>

hid-asus: Fix up Zenbook Duo report descriptors

This commit adds a quirk for the Zenbook Duo 2024+ keyboards to fix up an
unmapped Asus vendor usage page code. It reuses the existing report
descriptor fixup logic previously used for T100CHI and T90CHI devices.

> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..ce246efba74d3 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c

[ ... ]

> @@ -1384,17 +1385,20 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
>  		hid_info(hdev, "Fixing up Asus T100 keyb report descriptor\n");
>  		rdesc[74] &= ~HID_MAIN_ITEM_CONSTANT;
>  	}
> -	/* For the T100CHI/T90CHI keyboard dock */
> -	if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI)) {
> +	/* For the T100CHI/T90CHI keyboard dock and Zenbook Duo 2024+ keyboards */
> +	if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI | QUIRK_ZENBOOK_DUO_KEYBOARD)) {
>  		int rsize_orig;
>  		int offs;
>  
>  		if (drvdata->quirks & QUIRK_T100CHI) {
>  			rsize_orig = 403;
>  			offs = 388;
> -		} else {
> +		} else if (drvdata->quirks & QUIRK_T90CHI) {
>  			rsize_orig = 306;
>  			offs = 291;
> +		} else if (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) {
> +			rsize_orig = 257;
> +			offs = 176;
>  		}

Could this introduce a regression by corrupting the Zenbook Duo report
descriptor when failing to shift the remainder of the items correctly?

For the Zenbook Duo, the descriptor is 257 bytes long and the offset is 176,
leaving 79 bytes after the replaced item. However, the shared fixup logic
below this code hardcodes a memmove of exactly 12 bytes:

drivers/hid/hid-asus.c:asus_report_fixup() {
    ...
    memcpy(new_rdesc, rdesc, rsize_orig);
    *rsize = rsize_orig + 1;
    rdesc = new_rdesc;

    memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
    rdesc[offs] = 0x19;
    ...
}

Does shifting only 12 bytes overwrite the valid original bytes at offsets 190
and 191, and leave the remaining 67 bytes unshifted?

Additionally, does the new_rdesc allocation properly account for the shift?

Replacing a 2-byte item with a 4-byte item requires shifting the remaining
items forward by 2 bytes. Allocating only rsize_orig + 1 could lead to a
1-byte out-of-bounds write if all 79 bytes are shifted properly.

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

[PATCH 2/7] hid-asus: Add missing Zenbook Duo hotkeys

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
---
 drivers/hid/hid-asus.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index ce246efba74d3..cba638b19465f 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1046,6 +1046,7 @@ static int asus_input_mapping(struct hid_device *hdev,
 		case 0x6c: asus_map_key_clear(KEY_SLEEP);		break;
 		case 0x7c: asus_map_key_clear(KEY_MICMUTE);		break;
 		case 0x82: asus_map_key_clear(KEY_CAMERA);		break;
+		case 0x86: asus_map_key_clear(KEY_CONTROLPANEL);	break; /* MyASUS */
 		case 0x88: asus_map_key_clear(KEY_RFKILL);			break;
 		case 0xb5: asus_map_key_clear(KEY_CALC);			break;
 		case 0xc4: asus_map_key_clear(KEY_KBDILLUMUP);		break;
@@ -1066,6 +1067,18 @@ static int asus_input_mapping(struct hid_device *hdev,
 		case 0xb3: asus_map_key_clear(KEY_PROG3);	break; /* Fn+Left next aura */
 		case 0x6a: asus_map_key_clear(KEY_F13);		break; /* Screenpad toggle */
 		case 0x4b: asus_map_key_clear(KEY_F14);		break; /* Arrows/Pg-Up/Dn toggle */
+		case 0x9c: asus_map_key_clear(KEY_F19);		break; /* Screen swap */
+
+		/* Mutually exclusive section: Special keys from different devices can
+		 * bind to the same keycodes without concern, as they will never
+		 * conflict.
+		 *
+		 * Note that devices with removable keyboards that connect over a
+		 * standard interface (e.g. Zenbook Duo UX8406 with USB/Bluetooth) do
+		 * not belong in this section, as such keyboards can be connected to
+		 * another ASUS device that also uses this driver for its own keyboard.
+		 */
+		/* ROG Ally */
 		case 0xa5: asus_map_key_clear(KEY_F15);		break; /* ROG Ally left back */
 		case 0xa6: asus_map_key_clear(KEY_F16);		break; /* ROG Ally QAM button */
 		case 0xa7: asus_map_key_clear(KEY_F17);		break; /* ROG Ally ROG long-press */
-- 
2.53.0

Re: [PATCH 2/7] hid-asus: Add missing Zenbook Duo hotkeys

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The 'MyASUS' key (0x86) mapping is inconsistent with the existing Asus WMI driver.
--

commit ee67c289461b2da1755d4534b96e25db841e41d8
Author: Joshua Leivenzon <hacker1024@users.sourceforge.net>

hid-asus: Add missing Zenbook Duo hotkeys

This commit adds input mappings for several missing Zenbook Duo hotkeys,
including the MyASUS key, screen swap, and ROG Ally buttons, handling
them through the hid-asus driver.

> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index ce246efba74d3..cba638b19465f 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1046,6 +1046,7 @@ static int asus_input_mapping(struct hid_device *hdev,
>  		case 0x6c: asus_map_key_clear(KEY_SLEEP);		break;
>  		case 0x7c: asus_map_key_clear(KEY_MICMUTE);		break;
>  		case 0x82: asus_map_key_clear(KEY_CAMERA);		break;
> +		case 0x86: asus_map_key_clear(KEY_CONTROLPANEL);	break; /* MyASUS */

Is it intentional to map the MyASUS key to KEY_CONTROLPANEL here?

The existing asus-nb-wmi driver maps the identical 0x86 hardware event
for the MyASUS key to KEY_PROG1.

Mapping this to KEY_CONTROLPANEL in the HID driver might introduce an
inconsistent contract for user-space, where the exact same physical
button on Asus devices yields different keycodes depending on whether the
event is routed through the HID or WMI subsystem.

Could this cause issues for desktop environments attempting to bind
device-specific hotkeys consistently?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513163248.16483-1-p.pisati@gmail.com?part=2

[PATCH 3/7] hid-asus: Add report descriptor fixup offsets for UX8406MA USB keyboard

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
---
 drivers/hid/hid-asus.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index cba638b19465f..2a88ce695489d 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1410,8 +1410,13 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 			rsize_orig = 306;
 			offs = 291;
 		} else if (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) {
-			rsize_orig = 257;
-			offs = 176;
+			if (hid_is_usb(hdev)) {
+				rsize_orig = 90;
+				offs = 66;
+			} else /* Bluetooth */ {
+				rsize_orig = 257;
+				offs = 176;
+			}
 		}
 
 		/*
-- 
2.53.0

[PATCH 4/7] hid-asus: Remove more bogus zero bytes from some report descriptors

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
---
 drivers/hid/hid-asus.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 2a88ce695489d..cf9184ed2d3ec 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1422,14 +1422,19 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		/*
 		 * Change Usage (76h) to Usage Minimum (00h), Usage Maximum
 		 * (FFh) and clear the flags in the Input() byte.
-		 * Note the descriptor has a bogus 0 byte at the end so we
-		 * only need 1 extra byte.
 		 */
 		if (*rsize == rsize_orig &&
 			rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
 			__u8 *new_rdesc;
+            unsigned int new_rsize = rsize_orig;
 
-			new_rdesc = devm_kzalloc(&hdev->dev, rsize_orig + 1,
+			/* Clear bogus trailing zero bytes. */
+			while (rdesc[new_rsize + 1] == 0)
+				--new_rsize;
+            /* Make room for the added bytes. */
+			new_rsize += 2;
+
+            new_rdesc = devm_kzalloc(&hdev->dev, new_rsize,
 						 GFP_KERNEL);
 			if (!new_rdesc)
 				return rdesc;
@@ -1439,8 +1444,8 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 				"T100CHI" : drvdata->quirks & QUIRK_T90CHI ?
 				"T90CHI" : "ZENBOOK DUO");
 
-			memcpy(new_rdesc, rdesc, rsize_orig);
-			*rsize = rsize_orig + 1;
+			memcpy(new_rdesc, rdesc, new_rsize);
+			*rsize = new_rsize;
 			rdesc = new_rdesc;
 
 			memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
-- 
2.53.0

Re: [PATCH 4/7] hid-asus: Remove more bogus zero bytes from some report descriptors

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The trailing zero removal loop reads past the end of the report descriptor buffer and lacks a lower bounds check.
- [High] The `memcpy` operation copies more bytes than are available in the source `rdesc` buffer.
- [High] Trimming trailing bytes can shrink the new buffer size below what is required for subsequent fixed-offset memory operations, causing a heap buffer overflow.
--

commit 1a97afa374b1aa0ec76a035ced7d0e6414476f71
Author: Joshua Leivenzon <hacker1024@users.sourceforge.net>

hid-asus: Remove more bogus zero bytes from some report descriptors

This commit attempts to remove bogus trailing zero bytes from specific
HID report descriptors. It adjusts the new report descriptor size by
stripping zeroes from the end and then allocates a new buffer.

> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
[ ... ]
>  		if (*rsize == rsize_orig &&
>  			rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
>  			__u8 *new_rdesc;
> +            unsigned int new_rsize = rsize_orig;
>  
> +			/* Clear bogus trailing zero bytes. */
> +			while (rdesc[new_rsize + 1] == 0)
> +				--new_rsize;

Since the rdesc buffer contains exactly rsize_orig bytes, does evaluating
rdesc[new_rsize + 1] read two bytes past the end of the allocation?

Additionally, if the adjacent memory happens to contain zeroes, could
new_rsize decrement indefinitely and underflow since there is no lower
bound check?

> +            /* Make room for the added bytes. */
> +			new_rsize += 2;
> +
> +            new_rdesc = devm_kzalloc(&hdev->dev, new_rsize,
>  						 GFP_KERNEL);
>  			if (!new_rdesc)
>  				return rdesc;
[ ... ]
> -			memcpy(new_rdesc, rdesc, rsize_orig);
> -			*rsize = rsize_orig + 1;
> +			memcpy(new_rdesc, rdesc, new_rsize);

If no trailing zeroes were stripped, new_rsize is now rsize_orig + 2. Does
this memcpy copy more bytes than are available in the original rdesc
buffer, leading to an out-of-bounds read?

> +			*rsize = new_rsize;
>  			rdesc = new_rdesc;
>  
>  			memmove(rdesc + offs + 4, rdesc + offs + 2, 12);

If trailing zeroes were successfully removed, could new_rsize drop below the
offsets used in this memmove and subsequent assignments?

For example, if new_rsize shrinks below offs + 15, will the fixed-offset
memmove and subsequent assignments write past the end of the newly allocated
new_rdesc buffer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513163248.16483-1-p.pisati@gmail.com?part=4

[PATCH 5/7] hid-asus: Fix input mapping on dedicated vendor HID interfaces

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
---
 drivers/hid/hid-asus.c | 44 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index cf9184ed2d3ec..fe52fd63d61c6 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1376,6 +1376,30 @@ static void asus_remove(struct hid_device *hdev)
 	hid_hw_stop(hdev);
 }
 
+/*
+ * Some USB keyboards, like the Zenbook Duo UX8406MA keyboard, have a dedicated
+ * USB interface for vendor-specific reports, separate to the generic HID
+ * keyboard or consumer control interfaces.
+ *
+ * The kernel does not register these vendor-specific interfaces as keyboards,
+ * or perform input mapping on them at all.
+ *
+ * To work around this, a fake keyboard input can be added to the
+ * vendor-specific interface's report descriptor. The kernel then combines it
+ * with the vendor-specific collections, and allows the interface to be used as
+ * a regular keyboard with our custom mappings.
+ */
+static const __u8 asus_fake_keyboard_rdesc[] = {
+	0x05, 0x01, /* Usage Page (Generic Desktop) */
+	0x09, 0x06, /* Usage (Keyboard) */
+	0xa1, 0x01, /* Collection (Application) */
+	0x85, 0x01, /*   Report ID (1) */
+	0x75, 0x08, /*   Report Size (8) */
+	0x95, 0x01, /*   Report Count (1) */
+	0x81, 0x00, /*   Input (Data,Arr,Abs) */
+	0xc0,       /* End Collection */
+};
+
 static const __u8 asus_g752_fixed_rdesc[] = {
         0x19, 0x00,			/*   Usage Minimum (0x00)       */
         0x2A, 0xFF, 0x00,		/*   Usage Maximum (0xFF)       */
@@ -1457,6 +1481,26 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		}
 	}
 
+	if ((drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) &&
+	    hid_is_usb(hdev) &&
+	    to_usb_interface(hdev->dev.parent)->altsetting->desc.bInterfaceNumber == 4) {
+
+		__u8 *new_rdesc;
+		size_t new_size = *rsize + sizeof(asus_fake_keyboard_rdesc);
+
+		new_rdesc = devm_kzalloc(&hdev->dev, new_size, GFP_KERNEL);
+		if (new_rdesc == NULL)
+			return rdesc;
+
+		hid_info(hdev, "Injecting virtual Zenbook Duo keyboard usage page\n");
+
+		memcpy(new_rdesc, asus_fake_keyboard_rdesc, sizeof(asus_fake_keyboard_rdesc));
+		memcpy(new_rdesc + sizeof(asus_fake_keyboard_rdesc), rdesc, *rsize);
+
+		*rsize = new_size;
+		rdesc = new_rdesc;
+	}
+
 	if (drvdata->quirks & QUIRK_G752_KEYBOARD &&
 		 *rsize == 75 && rdesc[61] == 0x15 && rdesc[62] == 0x00) {
 		/* report is missing usage minimum and maximum */
-- 
2.53.0

Re: [PATCH 5/7] hid-asus: Fix input mapping on dedicated vendor HID interfaces

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The injected fake keyboard descriptor contains a malformed padding item that violates the HID specification.
--

commit 98dabe022a958136634ce6b477391fa33ffa21b6
Author: Joshua Leivenzon <hacker1024@users.sourceforge.net>

hid-asus: Fix input mapping on dedicated vendor HID interfaces

This commit adds a fake keyboard input to the vendor-specific interface's
report descriptor on some USB keyboards, such as the Zenbook Duo UX8406MA.
This allows the kernel to combine it with the vendor-specific collections
and process the custom mappings correctly.

> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index cf9184ed2d3ec..fe52fd63d61c6 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1376,6 +1376,30 @@ static void asus_remove(struct hid_device *hdev)
>  	hid_hw_stop(hdev);
>  }
>  
> +/*
> + * Some USB keyboards, like the Zenbook Duo UX8406MA keyboard, have a dedicated
> + * USB interface for vendor-specific reports, separate to the generic HID
> + * keyboard or consumer control interfaces.
> + *
> + * The kernel does not register these vendor-specific interfaces as keyboards,
> + * or perform input mapping on them at all.
> + *
> + * To work around this, a fake keyboard input can be added to the
> + * vendor-specific interface's report descriptor. The kernel then combines it
> + * with the vendor-specific collections, and allows the interface to be used as
> + * a regular keyboard with our custom mappings.
> + */
> +static const __u8 asus_fake_keyboard_rdesc[] = {
> +	0x05, 0x01, /* Usage Page (Generic Desktop) */
> +	0x09, 0x06, /* Usage (Keyboard) */
> +	0xa1, 0x01, /* Collection (Application) */
> +	0x85, 0x01, /*   Report ID (1) */
> +	0x75, 0x08, /*   Report Size (8) */
> +	0x95, 0x01, /*   Report Count (1) */
> +	0x81, 0x00, /*   Input (Data,Arr,Abs) */

Does this Input item need to be declared as Constant?

According to the HID 1.11 specification, a field mapped as padding because
no usage is specified must be declared as Constant (e.g., 0x01 or 0x03).

Declaring it as Data (0x00) violates the protocol and could cause strict
user-space HID parsers reading the raw descriptor to reject it.

> +	0xc0,       /* End Collection */
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513163248.16483-1-p.pisati@gmail.com?part=5

[PATCH 6/7] hid-asus: Allow adding custom hotkey handler logic

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

Respond to platform profile cycle key:
Fn + F on UX8406MA.

May vary across devices.

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
---
 drivers/hid/hid-asus.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index fe52fd63d61c6..37e3aec612b6d 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -29,6 +29,7 @@
 #include <linux/input/mt.h>
 #include <linux/usb.h> /* For to_usb_interface for T100 touchpad intf check */
 #include <linux/power_supply.h>
+#include <linux/platform_profile.h>
 #include <linux/leds.h>
 
 #include "hid-ids.h"
@@ -362,8 +363,21 @@ static int asus_event(struct hid_device *hdev, struct hid_field *field,
 	if ((usage->hid & HID_USAGE_PAGE) == HID_UP_ASUSVENDOR &&
 	    (usage->hid & HID_USAGE) != 0x00 &&
 	    (usage->hid & HID_USAGE) != 0xff && !usage->type) {
-		hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
-			 usage->hid & HID_USAGE);
+
+		/*
+		 * Some reports do not map directly to standard keys, and need special
+		 * handling.
+		 */
+		switch (usage->hid & HID_USAGE) {
+			case 0x9d:
+				if (!value)
+					break;
+				return platform_profile_cycle();
+				break;
+			default:
+				hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
+					 usage->hid & HID_USAGE);
+		}
 	}
 
 	if (usage->type == EV_KEY && value) {
-- 
2.53.0

Re: [PATCH 6/7] hid-asus: Allow adding custom hotkey handler logic

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Calling platform_profile_cycle() from an atomic context causes a 'scheduling while atomic' bug.
- [High] Missing Kconfig dependency on ACPI_PLATFORM_PROFILE leads to a linker error.
- [Medium] Improper HID event return value causes spurious error logs and incorrect event propagation.
- [Low] Dead code due to unreachable break statement.
--

commit f4dcdddfbfb9d5acd09f6a961fcad0539b0cd8c7
Author: Joshua Leivenzon <hacker1024@users.sourceforge.net>

hid-asus: Allow adding custom hotkey handler logic

This commit modifies the Asus HID driver to handle a custom vendor hotkey
for cycling the platform profile when a specific usage code is received.

> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index fe52fd63d61c6..37e3aec612b6d 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -29,6 +29,7 @@
>  #include <linux/input/mt.h>
>  #include <linux/usb.h> /* For to_usb_interface for T100 touchpad intf check */
>  #include <linux/power_supply.h>
> +#include <linux/platform_profile.h>

Does the HID_ASUS Kconfig option need to depend on or select
ACPI_PLATFORM_PROFILE? If the kernel is built with
CONFIG_ACPI_PLATFORM_PROFILE=n, won't this result in a linker error since
platform_profile_cycle() is used unconditionally and there are no empty dummy
stubs provided in the header?

[ ... ]

> @@ -362,8 +363,21 @@ static int asus_event(struct hid_device *hdev, struct hid_field *field,
>  	if ((usage->hid & HID_USAGE_PAGE) == HID_UP_ASUSVENDOR &&
>  	    (usage->hid & HID_USAGE) != 0x00 &&
>  	    (usage->hid & HID_USAGE) != 0xff && !usage->type) {
> -		hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
> -			 usage->hid & HID_USAGE);
> +
> +		/*
> +		 * Some reports do not map directly to standard keys, and need special
> +		 * handling.
> +		 */
> +		switch (usage->hid & HID_USAGE) {
> +			case 0x9d:
> +				if (!value)
> +					break;
> +				return platform_profile_cycle();

Is it safe to call platform_profile_cycle() from here?

The asus_event() callback is invoked by the HID core in an atomic softirq
context when processing USB URB completions. However,
platform_profile_cycle() acquires profile_lock, which is a mutex. Will this
result in a scheduling while atomic panic? Should this action be deferred to
a workqueue, similar to how fn_lock_sync_work is handled?

Also, if platform_profile_cycle() returns a negative error code (like -EINVAL
when no profiles are registered), returning it directly here will cause
hid_process_event() to spam the kernel log with error messages on every key
press. Conversely, if it returns 0 on success, won't the HID core incorrectly
continue processing this event instead of treating it as consumed? Does this
need to handle the return value and return 1 to halt further event
processing?

> +				break;

This isn't a bug, but this break statement is unreachable since the previous
line always returns.

> +			default:
> +				hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
> +					 usage->hid & HID_USAGE);
> +		}
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513163248.16483-1-p.pisati@gmail.com?part=6

[PATCH 7/7] hid-asus: add prod-id, quirk for Zenbook Duo keyboard

[Paolo Pisati]

From: Luke Jones <luke@ljones.dev>

The 2024/2025/2026 ASUS Zenbook Duo has a similar keyboard setup as many of the ROG
range of laptops, with the same init sequence and control for backlight.
Enable the keyboard control and backlight by:
- adding the product ID for 2024/2025/2026 Zenbook Duo keyboard MCU
- adding the Bluetooth Zenbook Duo keyboard IDs
- use Fn-lock on Zenbook Duo keyboards

Intended for the UX8406-style product line with the fully removable keyboard.

Signed-off-by: Luke Jones <luke@ljones.dev>
Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Signed-off-by: Ivan Levchenko <me@livan.pro>
---
 drivers/hid/hid-asus.c | 18 ++++++++++++++++++
 drivers/hid/hid-ids.h  |  6 ++++++
 2 files changed, 24 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 37e3aec612b6d..ba093f11f802f 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1583,6 +1583,24 @@ static const struct hid_device_id asus_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
 	    USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR),
 	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
+	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_HID_FN_LOCK | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ASUSTEK,
+	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_HID_FN_LOCK | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
+	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_HID_FN_LOCK | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ASUSTEK,
+	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_HID_FN_LOCK | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
+	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_HID_FN_LOCK | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ASUSTEK,
+	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_HID_FN_LOCK | QUIRK_ZENBOOK_DUO_KEYBOARD },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
 	    USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY),
 	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_ROG_ALLY_XPAD},
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0cf63742315bf..97dc451adac5a 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -227,6 +227,12 @@
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD	0x1866
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2	0x19b6
 #define USB_DEVICE_ID_ASUSTEK_ROG_Z13_FOLIO		0x1a30
+#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD	0x1b2c
+#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD	0x1b2d
+#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD	0x1bf2
+#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD	0x1bf3
+#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD	0x1cd7
+#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD	0x1cd8
 #define USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR		0x18c6
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY		0x1abe
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY_X		0x1b4c
-- 
2.53.0

Re: [PATCH 7/7] hid-asus: add prod-id, quirk for Zenbook Duo keyboard

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Out-of-bounds read and heap buffer overflow in report descriptor fixup logic.
--

commit ad6b37250b171e419ae8bd990515ef1b0181a049
Author: Luke Jones <luke@ljones.dev>

hid-asus: add prod-id, quirk for Zenbook Duo keyboard

This commit adds product IDs and Bluetooth IDs for the 2024/2025/2026 ASUS
Zenbook Duo keyboards. It enables keyboard control, backlight, and Fn-lock
by applying the appropriate quirks.

> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 37e3aec612b6d..ba093f11f802f 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1583,6 +1583,24 @@ static const struct hid_device_id asus_devices[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
>  	    USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR),
>  	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
> +	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> +	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD),
> +	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_HID_FN_LOCK | QUIRK_ZENBOOK_DUO_KEYBOARD },

This isn't a bug introduced in this patch, but adding these new device IDs with
QUIRK_ZENBOOK_DUO_KEYBOARD exposes them to an existing out-of-bounds read and
heap buffer overflow in asus_report_fixup().

When a device with this quirk connects, the driver attempts to strip trailing
zeros from its report descriptor:

drivers/hid/hid-asus.c:asus_report_fixup() {
    ...
    if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI | QUIRK_ZENBOOK_DUO_KEYBOARD)) {
        ...
        if (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) {
            if (hid_is_usb(hdev)) {
                rsize_orig = 90;
                offs = 66;
            ...
        }
        
        if (*rsize == rsize_orig &&
            rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
            __u8 *new_rdesc;
            unsigned int new_rsize = rsize_orig;

            /* Clear bogus trailing zero bytes. */
            while (rdesc[new_rsize + 1] == 0)
                --new_rsize;
    ...
}

Does this evaluate rdesc[new_rsize + 1] reading 2 bytes past the end of the
dynamically allocated descriptor buffer, since new_rsize is initialized to the
exact size of the descriptor?

Furthermore, if the out-of-bounds bytes are non-zero, new_rsize remains its
original value. The code then copies rsize_orig + 2 bytes from the
rsize_orig-sized buffer:

drivers/hid/hid-asus.c:asus_report_fixup() {
    ...
            new_rsize += 2;
            new_rdesc = devm_kzalloc(&hdev->dev, new_rsize, GFP_KERNEL);
            ...
            memcpy(new_rdesc, rdesc, new_rsize);
    ...
}

Can this result in an unconditional slab-out-of-bounds read?

Finally, if new_rsize shrank below offs + 14 due to trailing zeros, could the
subsequent memmove and assignments write past the end of the newly allocated
buffer, causing a heap buffer overflow?

drivers/hid/hid-asus.c:asus_report_fixup() {
    ...
            memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
            ...
            rdesc[offs + 14] = 0x00;
    ...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513163248.16483-1-p.pisati@gmail.com?part=7