linux-kernel - Re: [PATCH] x86: mcheck: call put_device on device

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] [day] [month] [year] [list]

Date:	Thu, 05 Dec 2013 12:18:37 +0100
From:	Levente Kurusa <levex@...ux.com>
To:	Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tony Luck <tony.luck@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	EDAC <linux-edac@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: mcheck: call put_device on device_register failure

2013-12-05 03:57 keltezéssel, Chen, Gong írta:
> On Wed, Dec 04, 2013 at 07:39:07PM +0100, Levente Kurusa wrote:
>> Date:	Wed, 04 Dec 2013 19:39:07 +0100
>> From: Levente Kurusa <levex@...ux.com>
>> To: Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>, Thomas
>>  Gleixner <tglx@...utronix.de>, Tony Luck <tony.luck@...el.com>, "H. Peter
>>  Anvin" <hpa@...or.com>, x86@...nel.org, EDAC <linux-edac@...r.kernel.org>,
>>  LKML <linux-kernel@...r.kernel.org>
>> Subject: Re: [PATCH] x86: mcheck: call put_device on device_register failure
>> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101
>>  Thunderbird/24.1.0
>>
>> 2013-12-04 08:38, Chen, Gong:
>>> On Tue, Dec 03, 2013 at 06:01:50PM +0100, Borislav Petkov wrote:
>>>> Date: Tue, 3 Dec 2013 18:01:50 +0100
>>>> From: Borislav Petkov <bp@...en8.de>
>>>> To: "Chen, Gong" <gong.chen@...ux.intel.com>
>>>> Cc: Levente Kurusa <levex@...ux.com>, Ingo Molnar <mingo@...nel.org>,
>>>>  Thomas Gleixner <tglx@...utronix.de>, Tony Luck <tony.luck@...el.com>, "H.
>>>>  Peter Anvin" <hpa@...or.com>, x86@...nel.org, EDAC
>>>>  <linux-edac@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
>>>> Subject: Re: [PATCH] x86: mcheck: call put_device on device_register failure
>>>> User-Agent: Mutt/1.5.21 (2010-09-15)
>>>>
>>>> Can you please fix your
>>>>
>>>> Mail-Followup-To:
>>>>
>>>> header? It is impossible to reply to your emails without fiddling with
>>>> the To: and Cc: by hand which gets very annoying over time.
>>>
>>> I add some configs in my muttrc. Hope it works.
>>>
>>>>
>>>> On Mon, Dec 02, 2013 at 09:23:30PM -0500, Chen, Gong wrote:
>>>>> I have some concerns about it. if device_register is failed, it will
>>>>> backtraces all kinds of conditions automatically, including put_device
>>>>> definately. So do we really need an extra put_device when it returns
>>>>> failure?
>>>>
>>>> Do you mean the "done:" label in device_add() which does put_device()
>>>> and which gets called by device_register()?
>>>>
>>>
>>> Not only. I noticed that another put_device under label "Error:".
>>>
>>
>> That label is called when we failed to add the kobject to its parent.
>> It just puts the parent of the device. I don't think it has anything
>> to do with us put_device()-ing the actual device too.
>>
> OK, you are right. I read some kobject related codes and get:
> 
> static inline void kref_init(struct kref *kref)
> {
>         atomic_set(&kref->refcount, 1);
> }
> 
> The init refcount is 1, which means even if we meet an error and put_device
> in device_add, we still need an extra put_device to make refcount = 0
> and then release the dev object.

Exactly. This is why the comment you have found later on. :-)
> 
> BTW, from the comments of device_register:
> 
> "NOTE: _Never_ directly free @dev after calling this function, even
>  if it returned an error! Always use put_device() to give up the
>  reference initialized in this function instead. "
> 
> Many caller don't follow this logic. For example:
> in arch/arm/common/locomo.c
> locomo_init_one_child
> ...
>         ret = device_register(&dev->dev);
>         if (ret) {
> out:
>                 kfree(dev);

Umm, but it frees dev which is a container_of dev->dev so dev->dev is not
even freed. This is a memleak as well.
>         }
> ...
>  
> in arch/parisc/kernel/drivers.c
> create_tree_node
> ...
>         if (device_register(&dev->dev)) {
>                 kfree(dev);

Same here.
>                 return NULL;
>         }
> ...
> 
> etc.
> 
> Maybe we need one more patch to fix them all. :-)

Yes, I will post a series which fixes this during the weekend when I am not that busy. :-)

-- 
Regards,
Levente Kurusa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/