All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Jiri Kosina <jikos@kernel.org>,
	Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Cc: Benjamin Tissoires <bentiss@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	linux-usb@vger.kernel.org, linux-input@vger.kernel.org,
	syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org,
	syzbot+c52569baf0c843f35495@syzkaller.appspotmail.com,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH] HID: usbhid: fix recurrent out-of-bounds bug in usbhid_parse()
Date: Tue, 04 Jun 2024 07:11:16 -0700	[thread overview]
Message-ID: <E62FA5CB-D7AE-4A11-9D2E-7D78D7C10ADA@kernel.org> (raw)
In-Reply-To: <nycvar.YFH.7.76.2406041015210.16865@cbobk.fhfr.pm>



On June 4, 2024 1:15:35 AM PDT, Jiri Kosina <jikos@kernel.org> wrote:
>On Fri, 24 May 2024, Nikita Zhandarovich wrote:
>
>> Syzbot reports [1] a reemerging out-of-bounds bug regarding hid
>> descriptors possibly having incorrect bNumDescriptors values in
>> usbhid_parse().
>> 
>> Build on the previous fix in "HID: usbhid: fix out-of-bounds bug"
>> and run a sanity-check ensuring that number of descriptors doesn't
>> exceed the size of desc[] in struct hid_descriptor.
>> 
>> [1] Syzbot report:
>> Link: https://syzkaller.appspot.com/bug?extid=c52569baf0c843f35495
>> 
>> UBSAN: array-index-out-of-bounds in drivers/hid/usbhid/hid-core.c:1024:7
>> index 1 is out of range for type 'struct hid_class_descriptor[1]'
>> CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-rc6-syzkaller-00290-gb9158815de52 #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
>> Workqueue: usb_hub_wq hub_event
>> Call Trace:
>>  <TASK>
>>  __dump_stack lib/dump_stack.c:88 [inline]
>>  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
>>  ubsan_epilogue lib/ubsan.c:231 [inline]
>>  __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429
>>  usbhid_parse+0x5a7/0xc80 drivers/hid/usbhid/hid-core.c:1024
>>  hid_add_device+0x132/0x520 drivers/hid/hid-core.c:2790
>>  usbhid_probe+0xb38/0xea0 drivers/hid/usbhid/hid-core.c:1429
>>  usb_probe_interface+0x645/0xbb0 drivers/usb/core/driver.c:399
>>  really_probe+0x2b8/0xad0 drivers/base/dd.c:656
>>  __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:798
>>  driver_probe_device+0x50/0x430 drivers/base/dd.c:828
>>  __device_attach_driver+0x2d6/0x530 drivers/base/dd.c:956
>>  bus_for_each_drv+0x24e/0x2e0 drivers/base/bus.c:457
>>  __device_attach+0x333/0x520 drivers/base/dd.c:1028
>>  bus_probe_device+0x189/0x260 drivers/base/bus.c:532
>>  device_add+0x8ff/0xca0 drivers/base/core.c:3720
>>  usb_set_configuration+0x1976/0x1fb0 drivers/usb/core/message.c:2210
>>  usb_generic_driver_probe+0x88/0x140 drivers/usb/core/generic.c:254
>>  usb_probe_device+0x1b8/0x380 drivers/usb/core/driver.c:294
>> 
>> Reported-and-tested-by: syzbot+c52569baf0c843f35495@syzkaller.appspotmail.com
>> Fixes: f043bfc98c19 ("HID: usbhid: fix out-of-bounds bug")
>> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
>
>Applied, thanks.

This isn't the right solution. The problem is that hid_class_descriptor is a flexible array but was sized as a single element fake flexible array: 

struct hid_descriptor {
	   __u8  bLength;
	   __u8  bDescriptorType;
	   __le16 bcdHID;
	   __u8  bCountryCode;
	   __u8  bNumDescriptors;

	   struct hid_class_descriptor desc[1];
} __attribute__ ((packed));

This likely needs to be: 

struct hid_class_descriptor desc[] __counted_by(bNumDescriptors);

And then check for any sizeof() uses of the struct that might have changed.



-- 
Kees Cook

  reply	other threads:[~2024-06-04 14:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-24 12:01 [PATCH] HID: usbhid: fix recurrent out-of-bounds bug in usbhid_parse() Nikita Zhandarovich
2024-06-04  8:15 ` Jiri Kosina
2024-06-04 14:11   ` Kees Cook [this message]
2024-06-04 14:15     ` Jiri Kosina
2024-06-04 17:09       ` Nikita Zhandarovich
2024-06-04 17:21         ` Kees Cook
2024-06-04 17:45           ` Alan Stern
2025-01-28 13:45             ` Nikita Zhandarovich
2025-01-28 17:00               ` Alan Stern
2025-01-29  1:53                 ` Kees Cook
2025-01-29 19:21                   ` Terry Junge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E62FA5CB-D7AE-4A11-9D2E-7D78D7C10ADA@kernel.org \
    --to=kees@kernel.org \
    --cc=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=n.zhandarovich@fintech.ru \
    --cc=syzbot+c52569baf0c843f35495@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.