linux-kernel - Re: [PATCH v2 1/1] mux: mux-core: Add NULL check for dev->of

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: <591290e2-5c63-52c2-b5a3-5417bc16dc27@axentia.se>
Date:   Sun, 9 Jul 2017 09:07:55 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     "Kuppuswamy, Sathyanarayanan" <sathyaosid@...il.com>,
        sathyanarayanan.kuppuswamy@...ux.intel.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] mux: mux-core: Add NULL check for dev->of_node

On 2017-07-09 01:12, Kuppuswamy, Sathyanarayanan wrote:
> Hi Peter,
> 
> 
> On 7/8/2017 2:00 PM, Peter Rosin wrote:
>> On 2017-07-07 23:46, sathyanarayanan.kuppuswamy@...ux.intel.com wrote:
>>> From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
>>>
>>> If dev->of_node is NULL, then calling mux_control_get()
>>> function can lead to NULL pointer exception. So adding
>>> a NULL check for dev->of_node.
>>>
>>> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
>> Do you have a driver that might call mux_control_get and not have any
>> of_node?
> For non-device tree drivers, this case is valid. I hit this issue when I 
> was working on Intel USB MUX driver.
>>   If not, I don't see the point of this check.
> Since this is an API for other consumers, I think its better to have 
> some sanity checks.
> 
> If a non device tree driver call this API , I think its better to fail 
> with some error no instead of creating null pointer exception.

Is it? When authoring a new driver, and you make some error like this, why
is a "nice" error better than a big fat fail? If you get a null deref,
you will presumably also get a call stack etc, which will help you find
where you made the error, w/o adding a bunch of traces to find out exactly
what you did wrong.

So, I'm skeptic...

Cheers,
peda

>>
>> Cheers,
>> peda
>>
>>> ---
>>>   drivers/mux/mux-core.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> Changes since v1:
>>>   * Removed dummy new line.
>>>
>>> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
>>> index 90b8995..924c983 100644
>>> --- a/drivers/mux/mux-core.c
>>> +++ b/drivers/mux/mux-core.c
>>> @@ -438,6 +438,9 @@ struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
>>>   	int index = 0;
>>>   	int ret;
>>>   
>>> +	if (!np)
>>> +		return ERR_PTR(-ENODEV);
>>> +
>>>   	if (mux_name) {
>>>   		index = of_property_match_string(np, "mux-control-names",
>>>   						 mux_name);
>>>
>