linux-kernel - Re: [PATCH] of: refcount leak when phandle

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 19 Dec 2019 09:57:17 -0600
From:   Frank Rowand <frowand.list@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Frank Rowand <frowand.list@...il.com>
Subject: Re: [PATCH] of: refcount leak when phandle_cache entry replaced

On 12/12/19 8:00 AM, Rob Herring wrote:
> On Thu, Dec 12, 2019 at 5:17 AM Frank Rowand <frowand.list@...il.com> wrote:
>>
>> On 12/11/19 2:18 PM, Rob Herring wrote:
>>> On Tue, 10 Dec 2019 02:14:53 -0600, frowand.list@...il.com wrote:
>>>> From: Frank Rowand <frank.rowand@...y.com>
>>>>
>>>> of_find_node_by_phandle() does not do an of_node_put() of the existing
>>>> node in a phandle cache entry when that node is replaced by a new node.
>>>>
>>>> Reported-by: Rob Herring <robh+dt@...nel.org>
>>>> Fixes: b8a9ac1a5b99 ("of: of_node_get()/of_node_put() nodes held in phandle cache")
>>>> Signed-off-by: Frank Rowand <frank.rowand@...y.com>
>>>> ---
>>>>
>>>> Checkpatch will warn about a line over 80 characters.  Let me know
>>>> if that bothers you.
>>>>
>>>>  drivers/of/base.c | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>
>>> Applied, thanks.
>>>
>>> Rob
>>>
>>
>> If the rework patch of the cache that you posted shortly after accepting
>> my patch, then my patch becomes not needed and is just extra noise in the
>> history.  Once your patch finishes review (I am assuming it probably
>> will), then my patch should be reverted.
> 
> The question is what to backport: nothing, this patch or mine? My
> thought was to apply this mainly to backport. If you're fine with
> nothing or mine, then we can drop it. I'm a bit nervous marking mine
> for stable.
> 
> Rob
> 

Your rework patch is slightly larger than what is preferred for stable,
but it is more likely that future patches to the files in the rework
patch will be able to be applied to stable.  So I am happy with
either nothing or your patch.

-Frank