linux-kernel - Re: [PATCH] firmware: arm_sdei: fix wrong of_node

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]

Message-ID: <cf4e5313-c467-8343-ac90-bb4b937b63ff@arm.com>
Date:   Fri, 21 Dec 2018 19:19:23 +0000
From:   James Morse <james.morse@....com>
To:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] firmware: arm_sdei: fix wrong of_node_put() in init
 function

Hi Nicolas,

On 03/12/2018 12:25, Nicolas Saenz Julienne wrote:
> On Fri, 2018-11-30 at 18:31 +0000, James Morse wrote:
>> On 26/11/2018 12:15, Nicolas Saenz Julienne wrote:
>>> After finding a "firmware" dt node arm_sdei tries to match it's
>>> compatible string with it. To do so it's calling
>>> of_find_matching_node()
>>> which already takes care of decreasing the refcount on the
>>> "firmware"
>>> node. We are then incorrectly decreasing the refcount on that node
>>> again.
>>>
>>> This patch removes the unwarranted call to of_node_put().
>>>
>>> Fixes: ad6eb31ef903 ("firmware: arm_sdei: Add driver for Software
>>> Delegated Exceptions")
>>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
>>
>> Thanks!, I agree this is unwarranted.
>> Is there a tool that picks these up? I remember sparse giving me a
>> headache, but
>> I don't remember this one... I probably cargo-culted it from
>> somewhere else.
> 
> We stumbled upon this one on a test system. TBH I don't really know
> much about these tools so I can't tell. That said, I sent 4 more fixes
> on this bug (one more in drivers/firmware) so there definitively was
> some cargo-culting happening.

Well this is embarrassing. I was trying to test this before re-posting it, to
discover dt-probing hasn't worked properly since it was merged, so I evidently
didn't test it properly after the merge-window. (at the same time the OF core
code took over creating platform devices from the firmware node, meaning my
attempt here fails, and the driver never gets registered).

I'll post the additional patch, and drop the fixes tag as this has never worked.


Thanks!

James