linux-kernel - Re: [PATCH net-next 1/2] nfc: s3fwrn5: fix order of freeing resources

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]

Date:   Thu, 29 Sep 2022 09:42:08 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Krzysztof Opasiak <k.opasiak@...sung.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] nfc: s3fwrn5: fix order of freeing resources

On 29/09/2022 09:37, Dmitry Torokhov wrote:
> On September 29, 2022 12:27:19 AM PDT, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> wrote:
>> On 29/09/2022 09:26, Krzysztof Kozlowski wrote:
>>> On 29/09/2022 07:04, Dmitry Torokhov wrote:
>>>> Caution needs to be exercised when mixing together regular and managed
>>>> resources. In case of this driver devm_request_threaded_irq() should
>>>> not be used, because it will result in the interrupt being freed too
>>>> late, and there being a chance that it fires up at an inopportune
>>>> moment and reference already freed data structures.
>>>
>>> Non-devm was so far recommended only for IRQF_SHARED, not for regular
>>> ones.
> 
> If we are absolutely sure there is no possibility of interrupts firing then devm
> should be ok, but it is much safer not to use it. Or use custom devm actions
> to free non-managed resources.

I am not sure and the pattern itself is a bit risky, I agree. However
the driver calls s3fwrn5_remove() which then calls
s3fwrn5_phy_power_ctrl() which cuts the power via GPIO pin. I assume
that the hardware should stop generating interrupts at this point.

> 
>>> Otherwise you have to fix half of Linux kernel drivers... 
> 
> Yes, if they are doing the wrong thing.

What I meant, that this pattern appears pretty often. If we agree that
this driver has a risky pattern (hardware might not be off after
remove() callback), then we should maybe document it somewhere and
include it in usual reviews.

Best regards,
Krzysztof