[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b40561a-580d-406a-bb2c-1398dce7fb90@kernel.org>
Date: Tue, 5 Nov 2024 08:40:43 +0100
From: Jiri Slaby <jirislaby@...nel.org>
To: Nolan Nicholson <nolananicholson@...il.com>, stable@...r.kernel.org
Cc: jikos@...nel.org, bentiss@...nel.org, linux-usb@...r.kernel.org,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
anssi.hannula@...il.com
Subject: Re: hid-pidff.c: null-pointer deref if optional HID reports are not
present
Cc Anssi
On 05. 11. 24, 1:30, Nolan Nicholson wrote:
> Hello,
>
> (This is my first time reporting a Linux bug; please accept my apologies
> for any mistakes in the process.)
>
> When initializing a HID PID device, hid-pidff.c checks for eight
> required HID reports and five optional reports. If the eight required
> reports are present, the hid_pidff_init() function then attempts to find
> the necessary fields in each required or optional report, using the
> pidff_find_fields() function. However, if any of the five optional
> reports is not present, pidff_find_fields() will trigger a null-pointer
> dereference.
>
> I recently implemented the descriptors for a USB HID device with PID
> force-feedback capability. After implementing the required report
> descriptors but not the optional ones, I got an OOPS from the
> pidff_find_fields function. I saved the OOPS from my Ubuntu
> installation, and have attached it here. I later reproduced the issue on
> 6.11.6.
>
> I was able to work around the issue by having my device present all of
> the optional report descriptors as well as all of the required ones.
Indeed. The code checks the required ones in pidff_reports_ok(). But the
optional ones are not checked at all and are directly accessed in both
pidff_init_fields() and also likely pidff_find_special_fields().
thanks,
--
js
suse labs
Powered by blists - more mailing lists