[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAO-hwJJ0Rxv6wJjRSEGyhQxKRW-iNSiO+8v-YgOa+cL4ZPSWRw@mail.gmail.com>
Date: Mon, 25 Nov 2019 10:33:08 +0100
From: Benjamin Tissoires <benjamin.tissoires@...hat.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Jiri Kosina <jikos@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] HID: hid-input: clear unmapped usages
Hi Dmitry,
On Fri, Nov 22, 2019 at 9:26 PM Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
>
> We should not be leaving half-mapped usages with potentially invalid
> keycodes, as that may confuse hidinput_find_key() when the key is
> located by index, which may end up feeding way too large keycode into
> the VT keyboard handler and cause OOB write there:
>
> BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
> BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
> BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
> Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
> ...
> kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
> kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
> input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
> input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
> input_pass_values drivers/input/input.c:949 [inline]
> input_set_keycode+0x290/0x320 drivers/input/input.c:954
> evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
> evdev_do_ioctl drivers/input/evdev.c:1150 [inline]
>
> In this case we were dealing with a fuzzed HID device that declared over
> 12K buttons:
>
> https://syzkaller.appspot.com/bug?extid=19340dff067c2d3835c0
>
> Reported-by: syzbot+19340dff067c2d3835c0@...kaller.appspotmail.com
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> ---
>
> I'll be putting a guard into drivers/tty/vt/keyboard.c as well.
> Please consider for stable.
>
> drivers/hid/hid-input.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 63855f275a38..3957d1c4d967 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1215,9 +1215,11 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> set_bit(MSC_SCAN, input->mscbit);
> }
>
> -ignore:
> return;
>
> +ignore:
> + usage->type = 0;
> + usage->code = 0;
Unfortunately, this breaks the buttons on the MS precision Touchpads.
The hid-tools test suite found that for me :)
The problem is:
hid-multitouch.c|mt_touch_input_mapping() lines 840-857
-> we assign the button mapping correctly, but there is a catch for
the first button:
hid-multitouch.c|mt_process_mt_event() lines 1123-1126
-> we check for the usage type and code to know which button we have
We are entering the ignore case because:
hid-input.c|hidinput_configure_usage() lines 582-589
-> hid-multitouch.c|mt_touch_input_mapping() lines 840-857
-> return 1
-> goto mapped
hid-input.c|hidinput_configure_usage() lines 1134-1137
-> hid-multitouch.c|mt_input_mapped() lines 1360-1363
-> return -1 (we are in the mt collection)
-> goto ignore
We would need to change the input_mapped() function to either ignore
or exit hidinput_configure_usage() based on the return value, or we
would need to store the original usages in hid-multitouch.
Actually, to fix this without breaking current drivers, we should just
change the `goto ignore` into a `return` after checking the value of
.input_mapped()
Cheers,
Benjamin
> }
>
> static void hidinput_handle_scroll(struct hid_usage *usage,
> --
> 2.24.0.432.g9d3f5f5b63-goog
>
>
> --
> Dmitry
>
Powered by blists - more mailing lists