Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 5 Nov 2023 18:36:52 +0100
From: Solar Designer <>
To: Pietro Borrello <>
Subject: Re: Linux Kernel: hid: type confusions on hid report_list entry

On Tue, Jan 17, 2023 at 06:05:30PM +0100, Pietro Borrello wrote:
> We found potential misuses of list_entry() on lists in hid driver
> code that are not checked, specifically hid_validate_values() in
> drivers/hid/hid-core.c and bigben_probe() in drivers/hid/hid-bigbenff.c.
> Issuing a list_entry() on an empty list causes a type confusion making
> the list_entry point to the list_head itself.
> The most impactful seems the missing check for an empty list in
> hid_validate_values() which is supposed to check the validity of the
> reports themselves, potentially affecting all the drivers that rely on it.
> The problem is caused by the driver's assumption that the device must
> have a valid report_list. While this will be true for all normal HID
> devices, a suitably malicious device can violate the assumption.
> At a first glance, it may seem that the patches have security implications.
> However, when plugging a device which provides a descriptor with no output
> report, the type confusions will create a fake struct hid_report*
> which points to ((struct hid_device *)hid).report_enum[type].report_list.
> This, by chance, makes the type confused structure to span
> the `struct hid_report* report_id_hash[256]` array in the
> ((struct hid_device *)hid).report_enum[type] field.
> Then, due to their semantics hid_validate_values() will check
> (report->maxfield > field_index) on the type-confused report,
> and the maxfield field happens to overlap on the
> report_id_hash[] array in the report_enum[type] field
> which are all NULL since we provided no reports.
> Similarly, for bigben_probe(), the confused report entry is
> used in the bigben_worker() function which checks
> (report->field[0] != NULL) that, again, overlaps with a NULL
> pointer.
> It seems there is a commit (918aa1ef104d: "HID: bigbenff: prevent
> null pointer dereference") which added the check for report_field
> being NULL to bigben_worker() to prevent crashing, but without
> checking the actual root cause.
> Thus, while being type confusions bugs, they are not exploitable.
> The list checks should be added also to prevent future exploitability
> if the shape of the structure changes (e.g., structure layout
> randomization), and they do not overlap anymore with NULL pointers.
> In this case, it is not exploitable just by the pure chance of struct
> member ordering.
> This post has been written in accordance with linux-distros rules to
> which we disclosed the initial findings of the potential vulnerabilities.
> as even if the bugs seem not exploitable, the wider community on
> oss-security might see how the issue does have security relevance.
> We submitted patches to fix the issue by checking that the lists
> are non-empty before allowing them to be used:

This was assigned CVE-2023-1073, which also covers a bug mentioned in
another oss-security posting below:

CVE-2023-1073 - Type Confusion in hid_validate_values()

CVE-2023-1073 - Type Confusion in bigben_probe()

CVE-2023-1073 - NULL Ptr Deref in betopff_init()


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.