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
| ||
|
Date: Wed, 23 Feb 2022 15:22:44 +0100 From: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com> To: Robin Murphy <robin.murphy@....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 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. > > 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? Best regards, Krzysztof
Powered by blists - more mailing lists