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: <cc8a0aa304a15fbdf2f433f98c645b7e962450f1.camel@inka.de>
Date:   Thu, 03 Nov 2022 16:22:15 +0100
From:   Enrik Berkhan <Enrik.Berkhan@...a.de>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>
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 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/

Cheers,
Enrik