From: Lee Jones <lee.jones@linaro.org>
To: Rodolfo Giometti <giometti@enneenne.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
David Laight <David.Laight@aculab.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Eurotech S.p.A" <info@eurotech.it>,
Geert Uytterhoeven <geert+renesas@glider.be>
Subject: Re: [PATCH 1/2] misc: c2port: core: Make copying name from userspace more secure
Date: Tue, 3 Nov 2020 08:57:26 +0000 [thread overview]
Message-ID: <20201103085726.GN4488@dell> (raw)
In-Reply-To: <9f10500a-cfd7-bcbe-7b8e-edd49ab4d43c@enneenne.com>
On Mon, 02 Nov 2020, Rodolfo Giometti wrote:
> On 02/11/2020 14:47, Lee Jones wrote:
> > On Mon, 02 Nov 2020, gregkh@linuxfoundation.org wrote:
> >
> >> On Mon, Nov 02, 2020 at 12:43:01PM +0000, Lee Jones wrote:
> >>> On Mon, 02 Nov 2020, gregkh@linuxfoundation.org wrote:
> >>>
> >>>> On Mon, Nov 02, 2020 at 11:49:03AM +0000, Lee Jones wrote:
> >>>>> On Mon, 02 Nov 2020, David Laight wrote:
> >>>>>
> >>>>>> From: Lee Jones
> >>>>>>> Sent: 02 November 2020 11:12
> >>>>>>>
> >>>>>>> strncpy() may not provide a NUL terminator, which means that a 1-byte
> >>>>>>> leak would be possible *if* this was ever copied to userspace. Ensure
> >>>>>>> the buffer will always be NUL terminated by using the kernel's
> >>>>>>> strscpy() which a) uses the destination (instead of the source) size
> >>>>>>> as the bytes to copy and b) is *always* NUL terminated.
> >>>>>>>
> >>>>>>> Cc: Rodolfo Giometti <giometti@enneenne.com>
> >>>>>>> Cc: "Eurotech S.p.A" <info@eurotech.it>
> >>>>>>> Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>>>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
> >>>>>>> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >>>>>>> ---
> >>>>>>> drivers/misc/c2port/core.c | 2 +-
> >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/misc/c2port/core.c b/drivers/misc/c2port/core.c
> >>>>>>> index 80d87e8a0bea9..b96444ec94c7e 100644
> >>>>>>> --- a/drivers/misc/c2port/core.c
> >>>>>>> +++ b/drivers/misc/c2port/core.c
> >>>>>>> @@ -923,7 +923,7 @@ struct c2port_device *c2port_device_register(char *name,
> >>>>>>> }
> >>>>>>> dev_set_drvdata(c2dev->dev, c2dev);
> >>>>>>>
> >>>>>>> - strncpy(c2dev->name, name, C2PORT_NAME_LEN - 1);
> >>>>>>> + strscpy(c2dev->name, name, sizeof(c2dev->name));
> >>>>>>
> >>>>>> strscpy() doesn't zero fill so if the memory isn't zeroed
> >>>>>> and a 'blind' copy to user of the structure is done
> >>>>>> then more data is leaked.
> >>>>>>
> >>>>>> strscpy() may be better, but rational isn't right.
> >>>>>
> >>>>> The original patch zeroed the data too, but I was asked to remove that
> >>>>> part [0]. In your opinion, should it be reinstated?
> >>>>>
> >>>>> [0] https://lore.kernel.org/patchwork/patch/1272290/
> >>>>
> >>>> Just keep the kzalloc() part of the patch, this portion makes no sense
> >>>> to me.
> >>>
> >>> Can do.
> >>>
> >>>> But if you REALLY want to get it correct, call dev_set_name()
> >>>> instead please, as that is what it is there for.
> >>>
> >>> The line above isn't setting the 'struct device' name. It looks as
> >>> though 'struct c2port' has it's own member, also called 'name'. As to
> >>> how they differ, I'm not currently aware. Nor do I wish to mess
> >>> around with the semantics all that much.
> >>>
> >>> Going with suggestion #1.
> >>
> >> As the "device" already has a name, I suggest just getting rid of this
> >> name field anyway, no need for duplicates.
> >
> > That definitely goes against the point I made above:
> >
> > "Nor do I wish to mess around with the semantics all that much."
> >
> > It looks as though the device name 'c2port%d' varies greatly to the
> > requested name 'uc'. I don't have enough knowledge of how user-
> > space expects to use the provided sysfs entries to be able to
> > competently merge/decide which of these should be kept and which to
> > discard.
> >
> > Hopefully one of the authors/maintainers are reading this and can come
> > up with an acceptable solution.
>
> User-space usage can change its behavior so, please, consider the best solution
> from the kernel space point-of-view. :)
If you're sure, I can add it to my TODO.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2020-11-03 8:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-02 11:12 [PATCH 1/2] misc: c2port: core: Make copying name from userspace more secure Lee Jones
2020-11-02 11:12 ` [PATCH 2/2] misc: ocxl: config: Rename function attribute description Lee Jones
2020-11-02 11:12 ` Lee Jones
[not found] ` <d7b2a5d8d46e4f7885315ea4aa032b8c@AcuMS.aculab.com>
2020-11-02 11:49 ` [PATCH 1/2] misc: c2port: core: Make copying name from userspace more secure Lee Jones
2020-11-02 12:11 ` gregkh
2020-11-02 12:43 ` Lee Jones
2020-11-02 12:59 ` gregkh
2020-11-02 13:47 ` Lee Jones
2020-11-02 14:31 ` Rodolfo Giometti
2020-11-03 8:57 ` Lee Jones [this message]
2020-11-03 9:20 ` Rodolfo Giometti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201103085726.GN4488@dell \
--to=lee.jones@linaro.org \
--cc=David.Laight@aculab.com \
--cc=arnd@arndb.de \
--cc=geert+renesas@glider.be \
--cc=giometti@enneenne.com \
--cc=gregkh@linuxfoundation.org \
--cc=info@eurotech.it \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.