| Message ID | 20211028205542.499280-1-linux@weissschuh.net (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 3e6a950d98366f5e716904e9a7e8ffc7ed638bd6 |
| Delegated to: | Jiri Kosina |
| Headers | show |
| Series | HID: input: set usage type to key on keycode remap | expand |
On Thu, Oct 28, 2021 at 10:55:42PM +0200, Thomas Weißschuh wrote: > When a scancode is manually remapped that previously was not handled as > key, then the old usage type was incorrectly reused. > > This caused issues on a "04b3:301b IBM Corp. SK-8815 Keyboard" which has > marked some of its keys with an invalid HID usage. These invalid usage > keys are being ignored since support for USB programmable buttons was > added. > > The scancodes are however remapped explicitly by the systemd hwdb to the > keycodes that are printed on the physical buttons. During this mapping > step the existing usage is retrieved which will be found with a default > type of 0 (EV_SYN) instead of EV_KEY. > > The events with the correct code but EV_SYN type are not forwarded to > userspace. > > This also leads to a kernel oops when trying to print the report descriptor > via debugfs. hid_resolv_event() tries to resolve a EV_SYN event with an > EV_KEY code which leads to an out-of-bounds access in the EV_SYN names > array. > > Fixes: bcfa8d1457 ("HID: input: Add support for Programmable Buttons") > Fixes: f5854fad39 ("Input: hid-input - allow mapping unknown usages") > Reported-by: Brent Roman <brent@mbari.org> > Tested-by: Brent Roman <brent@mbari.org> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Makes sense. Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > --- > drivers/hid/hid-input.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c > index 4b5ebeacd283..21d8cc64064d 100644 > --- a/drivers/hid/hid-input.c > +++ b/drivers/hid/hid-input.c > @@ -160,6 +160,7 @@ static int hidinput_setkeycode(struct input_dev *dev, > if (usage) { > *old_keycode = usage->type == EV_KEY ? > usage->code : KEY_RESERVED; > + usage->type = EV_KEY; > usage->code = ke->keycode; > > clear_bit(*old_keycode, dev->keybit); > > base-commit: 42d43c92fc577dca59ed74aec7868abec8d6ca6e > -- > 2.33.1 > Thanks.
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c index 4b5ebeacd283..21d8cc64064d 100644 --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -160,6 +160,7 @@ static int hidinput_setkeycode(struct input_dev *dev, if (usage) { *old_keycode = usage->type == EV_KEY ? usage->code : KEY_RESERVED; + usage->type = EV_KEY; usage->code = ke->keycode; clear_bit(*old_keycode, dev->keybit);
When a scancode is manually remapped that previously was not handled as key, then the old usage type was incorrectly reused. This caused issues on a "04b3:301b IBM Corp. SK-8815 Keyboard" which has marked some of its keys with an invalid HID usage. These invalid usage keys are being ignored since support for USB programmable buttons was added. The scancodes are however remapped explicitly by the systemd hwdb to the keycodes that are printed on the physical buttons. During this mapping step the existing usage is retrieved which will be found with a default type of 0 (EV_SYN) instead of EV_KEY. The events with the correct code but EV_SYN type are not forwarded to userspace. This also leads to a kernel oops when trying to print the report descriptor via debugfs. hid_resolv_event() tries to resolve a EV_SYN event with an EV_KEY code which leads to an out-of-bounds access in the EV_SYN names array. Fixes: bcfa8d1457 ("HID: input: Add support for Programmable Buttons") Fixes: f5854fad39 ("Input: hid-input - allow mapping unknown usages") Reported-by: Brent Roman <brent@mbari.org> Tested-by: Brent Roman <brent@mbari.org> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> --- drivers/hid/hid-input.c | 1 + 1 file changed, 1 insertion(+) base-commit: 42d43c92fc577dca59ed74aec7868abec8d6ca6e