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: <1b81d1ec-3050-b983-654b-52c955091274@linaro.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ