linux-kernel - Re: NULL pointer dereferences in hid-mcp2221

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d9bbc0ab-2541-6490-d852-c7e73e1f45fb@infradead.org>
Date:   Thu, 3 Nov 2022 09:13:54 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Enrik Berkhan <Enrik.Berkhan@...a.de>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:     Sven Zühlsdorf <sven.zuehlsdorf@...em.de>,
        Rishi Gupta <gupt21@...il.com>, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: NULL pointer dereferences in hid-mcp2221



On 11/3/22 08:22, Enrik Berkhan wrote:
> On Thu, 2022-11-03 at 13:16 +0100, Benjamin Tissoires wrote:
>> On Nov 02 2022, Randy Dunlap wrote:
>>> Hi--
>>>
>>> [adding linux-input mailing list]
>>>
>>> On 10/25/22 00:39, Sven Zühlsdorf wrote:
>>>> Hi,
>>>>
>>>> I've run into two NULL pointer dereferences when loading the MCP2221 driver.
>>>> Initially I observed them running the kernel used by yocto kirkstone
>>>> (currently 5.15.68) but can reproduce them with a vanilla 6.1-rc1 as well.
>>>> All line numbers below are for hid-mcp2221.c, taken from 6.1-rc1.
>>>>
>>>> The first one was easy to identify, in mcp2221_probe line 874 `hdev->hidraw`
>>>> was NULL since I compiled the kernel without CONFIG_HIDRAW enabled. Should
>>>> CONFIG_HID_MCP2221 perhaps depend on or imply CONFIG_HIDRAW?
>>>
>>> Looks to me like it should. Hopefully the HID people can chime in here.
>>
>> I actually don't see why this driver (and hid-cp2112.c FWIW) should
>> depend on hidraw. To me, the reference to hidraw is just a nicer logging
>> message, but I have a hard time understanding how hidraw should be
>> involved in the driver, and if it were, how it could not break
>> everything.
>>
>> So IMO, we should probably change that line from the 2 drivers and
>> replace the hidraw part with the hid->id number which is unique.
> 
> Exactly. See also
> https://lore.kernel.org/linux-input/20220926202239.16379-2-Enrik.Berkhan@inka.de/

Great. Thanks.

-- 
~Randy