linux-kernel - Re: [RFT PATCH 0/3] Fix kfree() of const memory on setting driver

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: <e0bc8dd2-bea9-354b-3b48-3123e0bbf717@arm.com>
Date:   Wed, 23 Feb 2022 15:08:14 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Abel Vesa <abel.vesa@....com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, alsa-devel@...a-project.org
Subject: Re: [RFT PATCH 0/3] Fix kfree() of const memory on setting
 driver_override

On 2022-02-23 14:22, Krzysztof Kozlowski wrote:
> On 23/02/2022 15:04, Robin Murphy wrote:
>> On 2022-02-22 14:06, Krzysztof Kozlowski wrote:
>>> On 22/02/2022 14:51, Rasmus Villemoes wrote:
>>>> On 22/02/2022 14.27, Krzysztof Kozlowski wrote:
>>>>> Hi,
>>>>>
>>>>> Drivers still seem to use driver_override incorrectly. Perhaps my old
>>>>> patch makes sense now?
>>>>> https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/
>>>>>
>>>>> Not tested - please review and test (e.g. by writing to dirver_override
>>>>> sysfs entry with KASAN enabled).
>>>>
>>>> Perhaps it would make sense to update the core code to release using
>>>> kfree_const(), allowing drivers to set the initial value with
>>>> kstrdup_const(). Drivers that currently use kstrdup() or kasprintf()
>>>> will continue to work [but if they kstrdup() a string literal they could
>>>> be changed to use kstrdup_const].
>>>
>>> The core here means several buses, so the change would not be that
>>> small. However I don't see the reason why "driver_override" is special
>>> and should be freed with kfree_const() while most of other places don't
>>> use it.
>>>
>>> The driver_override field definition is here obvious: "char *", so any
>>> assignments of "const char *" are logically wrong (although GCC does not
>>> warn of this literal string const discarding). Adding kfree_const() is
>>> hiding the problem - someone did not read the definition of assigned field.
>>
>> That's not the issue, though, is it? If I take the struct
>> platform_device definition at face value, this should be perfectly valid:
>>
>> 	static char foo[] = "foo";
>> 	pdev->driver_override = &foo;
> 
> 
> Yes, that's not the issue. It's rather about the interface. By
> convention we do not modify string literals but "char *driver_override"
> indicates that this is modifiable memory. I would argue that it even
> means that ownership is passed. Therefore passing string literal to
> "char *driver_override" is wrong from logical point of view.
> 
> Plus, as you mentioned later, can lead to undefined behavior.

But does anything actually need to modify a driver_override string? I 
wouldn't have thought so. I see at least two buses that *do* define 
theirs as const char *, but still assume to kfree() them.

>> And in fact that's effectively how the direct assignment form works
>> anyway - string literals are static arrays of type char (or wchar_t),
>> *not* const char, however trying to modify them is undefined behaviour.
>>
>> There's a big difference between "non-const" and "kfree()able", and
>> AFAICS there's no obvious clue that the latter is actually a requirement.
> 
> Then maybe kfreeable should be made a requirement? Or at least clearly
> documented?

Indeed, there's clearly some room for improvement still. And I'm not 
suggesting that these changes aren't already sensible as they are, just 
that the given justification seems a little unfair :)

Even kfree_const() can't help if someone has put their string in the 
middle of some larger block of kmalloc()ed memory, so perhaps 
encouraging a dedicated setter function rather than just exposing a raw 
string pointer is the ideal solution in the long term.

Cheers,
Robin.