* Re: [PATCH] drivers/input: Remove all strcpy() uses in favor of strscpy()
2021-08-01 16:44 ` Kees Cook
@ 2021-08-01 17:19 ` Dmitry Torokhov
2021-08-02 16:17 ` Kees Cook
2021-08-03 7:07 ` Kees Cook
2021-08-07 14:02 ` Len Baker
2 siblings, 1 reply; 16+ messages in thread
From: Dmitry Torokhov @ 2021-08-01 17:19 UTC (permalink / raw)
To: Kees Cook
Cc: Len Baker, Russell King (Oracle),
Lee Jones, Uwe Kleine-König, linux-hardening, linux-input,
linux-kernel, Joe Perches
On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote:
> On Sun, Aug 01, 2021 at 05:57:32PM +0200, Len Baker wrote:
> > Hi,
> >
> > On Sun, Aug 01, 2021 at 04:00:00PM +0100, Russell King (Oracle) wrote:
> > > On Sun, Aug 01, 2021 at 04:43:16PM +0200, Len Baker wrote:
> > > > strcpy() performs no bounds checking on the destination buffer. This
> > > > could result in linear overflows beyond the end of the buffer, leading
> > > > to all kinds of misbehaviors. The safe replacement is strscpy().
> > > >
> > > > Signed-off-by: Len Baker <len.baker@gmx.com>
> > > > ---
> > > > This is a task of the KSPP [1]
> > > >
> > > > [1] https://github.com/KSPP/linux/issues/88
> > > >
> > > > drivers/input/keyboard/locomokbd.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/input/keyboard/locomokbd.c b/drivers/input/keyboard/locomokbd.c
> > > > index dae053596572..dbb3dc48df12 100644
> > > > --- a/drivers/input/keyboard/locomokbd.c
> > > > +++ b/drivers/input/keyboard/locomokbd.c
> > > > @@ -254,7 +254,7 @@ static int locomokbd_probe(struct locomo_dev *dev)
> > > > locomokbd->suspend_jiffies = jiffies;
> > > >
> > > > locomokbd->input = input_dev;
> > > > - strcpy(locomokbd->phys, "locomokbd/input0");
> > > > + strscpy(locomokbd->phys, "locomokbd/input0", sizeof(locomokbd->phys));
> > >
> > > So if the string doesn't fit, it's fine to silently truncate it?
> >
> > I think it is better than overflow :)
> >
> > > Rather than converting every single strcpy() in the kernel to
> > > strscpy(), maybe there should be some consideration given to how the
> > > issue of a strcpy() that overflows the buffer should be handled.
> > > E.g. in the case of a known string such as the above, if it's longer
> > > than the destination, should we find a way to make the compiler issue
> > > a warning at compile time?
> >
> > Good point. I am a kernel newbie and have no experience. So this
> > question should be answered by some kernel hacker :) But I agree
> > with your proposals.
> >
> > Kees and folks: Any comments?
> >
> > Note: Kees is asked the same question in [2]
> >
> > [2] https://lore.kernel.org/lkml/20210731135957.GB1979@titan/
>
> Hi!
>
> Sorry for the delay at looking into this. It didn't use to be a problem
> (there would always have been a compile-time warning generated for
> known-too-small cases), but that appears to have regressed when,
> ironically, strscpy() coverage was added. I've detailed it in the bug
> report:
> https://github.com/KSPP/linux/issues/88
>
> So, bottom line: we need to fix the missing compile-time warnings for
> strcpy() and strscpy() under CONFIG_FORTIFY_SOURCE=y.
Is it possible to have them warn always? Or that would be too many false
positives?
>
> In the past we'd tried to add a stracpy()[1] that would only work with
> const string sources. Linus got angry[2] about API explosion, though,
> so we're mostly faced with doing the strscpy() replacements.
I would like to have an API that would do compile-time checks and
BUILD_BUG_ON() for a few places in input drivers where we copy constant
strings. There is no reason to encumber the code with runtime checks,
and bombing out on compile instead of truncating would be nice.
>
> Another idea might be to have strcpy() do the "constant strings only"
> thing, leaving strscpy() for the dynamic lengths.
>
> One thing is clear: replacing strlcpy() with strscpy() is probably the
> easiest and best first step to cleaning up the proliferation of str*()
> functions.
OK, so the consensus is that we set this patch aside as it does not
really fix any issues (the strcpy() destination is 32 bytes and is big
enough to hold the string being copied)?
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] drivers/input: Remove all strcpy() uses in favor of strscpy()
2021-08-01 17:19 ` Dmitry Torokhov
@ 2021-08-02 16:17 ` Kees Cook
0 siblings, 0 replies; 16+ messages in thread
From: Kees Cook @ 2021-08-02 16:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Len Baker, Russell King (Oracle),
Lee Jones, Uwe Kleine-König, linux-hardening, linux-input,
linux-kernel, Joe Perches
On Sun, Aug 01, 2021 at 10:19:07AM -0700, Dmitry Torokhov wrote:
> On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote:
> > On Sun, Aug 01, 2021 at 05:57:32PM +0200, Len Baker wrote:
> > > Hi,
> > >
> > > On Sun, Aug 01, 2021 at 04:00:00PM +0100, Russell King (Oracle) wrote:
> > > > On Sun, Aug 01, 2021 at 04:43:16PM +0200, Len Baker wrote:
> > > > > strcpy() performs no bounds checking on the destination buffer. This
> > > > > could result in linear overflows beyond the end of the buffer, leading
> > > > > to all kinds of misbehaviors. The safe replacement is strscpy().
> > > > >
> > > > > Signed-off-by: Len Baker <len.baker@gmx.com>
> > > > > ---
> > > > > This is a task of the KSPP [1]
> > > > >
> > > > > [1] https://github.com/KSPP/linux/issues/88
> > > > >
> > > > > drivers/input/keyboard/locomokbd.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/input/keyboard/locomokbd.c b/drivers/input/keyboard/locomokbd.c
> > > > > index dae053596572..dbb3dc48df12 100644
> > > > > --- a/drivers/input/keyboard/locomokbd.c
> > > > > +++ b/drivers/input/keyboard/locomokbd.c
> > > > > @@ -254,7 +254,7 @@ static int locomokbd_probe(struct locomo_dev *dev)
> > > > > locomokbd->suspend_jiffies = jiffies;
> > > > >
> > > > > locomokbd->input = input_dev;
> > > > > - strcpy(locomokbd->phys, "locomokbd/input0");
> > > > > + strscpy(locomokbd->phys, "locomokbd/input0", sizeof(locomokbd->phys));
> > > >
> > > > So if the string doesn't fit, it's fine to silently truncate it?
> > >
> > > I think it is better than overflow :)
> > >
> > > > Rather than converting every single strcpy() in the kernel to
> > > > strscpy(), maybe there should be some consideration given to how the
> > > > issue of a strcpy() that overflows the buffer should be handled.
> > > > E.g. in the case of a known string such as the above, if it's longer
> > > > than the destination, should we find a way to make the compiler issue
> > > > a warning at compile time?
> > >
> > > Good point. I am a kernel newbie and have no experience. So this
> > > question should be answered by some kernel hacker :) But I agree
> > > with your proposals.
> > >
> > > Kees and folks: Any comments?
> > >
> > > Note: Kees is asked the same question in [2]
> > >
> > > [2] https://lore.kernel.org/lkml/20210731135957.GB1979@titan/
> >
> > Hi!
> >
> > Sorry for the delay at looking into this. It didn't use to be a problem
> > (there would always have been a compile-time warning generated for
> > known-too-small cases), but that appears to have regressed when,
> > ironically, strscpy() coverage was added. I've detailed it in the bug
> > report:
> > https://github.com/KSPP/linux/issues/88
> >
> > So, bottom line: we need to fix the missing compile-time warnings for
> > strcpy() and strscpy() under CONFIG_FORTIFY_SOURCE=y.
>
> Is it possible to have them warn always? Or that would be too many false
> positives?
There are actually no false positives right now (they were all fixed
before FORTIFY_SOURCE landed). Enabling it by default would likely mean
splitting compile-time checks from run-time checks... I'm kind of
already doing this in the recent memcpy() strictness series[1], so ...
maybe?
I think I'd like to land the memcpy() series first, then we can revisit
making it always warn.
> > In the past we'd tried to add a stracpy()[1] that would only work with
> > const string sources. Linus got angry[2] about API explosion, though,
> > so we're mostly faced with doing the strscpy() replacements.
>
> I would like to have an API that would do compile-time checks and
> BUILD_BUG_ON() for a few places in input drivers where we copy constant
> strings. There is no reason to encumber the code with runtime checks,
> and bombing out on compile instead of truncating would be nice.
In theory, this is provided by CONFIG_FORTIFY_SOURCE, though a recent
change broke a specific instance. I've added tests for this now to the
memcpy() series, and will get it fixed in there too.
> > Another idea might be to have strcpy() do the "constant strings only"
> > thing, leaving strscpy() for the dynamic lengths.
> >
> > One thing is clear: replacing strlcpy() with strscpy() is probably the
> > easiest and best first step to cleaning up the proliferation of str*()
> > functions.
>
> OK, so the consensus is that we set this patch aside as it does not
> really fix any issues (the strcpy() destination is 32 bytes and is big
> enough to hold the string being copied)?
I think that's fair.
-Kees
[1] https://lore.kernel.org/lkml/20210727205855.411487-1-keescook@chromium.org/
--
Kees Cook
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] drivers/input: Remove all strcpy() uses in favor of strscpy()
2021-08-01 16:44 ` Kees Cook
2021-08-01 17:19 ` Dmitry Torokhov
@ 2021-08-03 7:07 ` Kees Cook
2021-08-03 7:18 ` Hans Verkuil
2021-08-07 14:02 ` Len Baker
2 siblings, 1 reply; 16+ messages in thread
From: Kees Cook @ 2021-08-03 7:07 UTC (permalink / raw)
To: Len Baker
Cc: Russell King (Oracle),
Dmitry Torokhov, Lee Jones, Uwe Kleine-König,
linux-hardening, linux-input, linux-kernel, Joe Perches,
Mauro Carvalho Chehab, linux-media
On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote:
> On Sun, Aug 01, 2021 at 05:57:32PM +0200, Len Baker wrote:
> > Hi,
> >
> > On Sun, Aug 01, 2021 at 04:00:00PM +0100, Russell King (Oracle) wrote:
> > > On Sun, Aug 01, 2021 at 04:43:16PM +0200, Len Baker wrote:
> > > > strcpy() performs no bounds checking on the destination buffer. This
> > > > could result in linear overflows beyond the end of the buffer, leading
> > > > to all kinds of misbehaviors. The safe replacement is strscpy().
> > > >
> > > > Signed-off-by: Len Baker <len.baker@gmx.com>
> > > > ---
> > > > This is a task of the KSPP [1]
> > > >
> > > > [1] https://github.com/KSPP/linux/issues/88
> > > >
> > > > drivers/input/keyboard/locomokbd.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/input/keyboard/locomokbd.c b/drivers/input/keyboard/locomokbd.c
> > > > index dae053596572..dbb3dc48df12 100644
> > > > --- a/drivers/input/keyboard/locomokbd.c
> > > > +++ b/drivers/input/keyboard/locomokbd.c
> > > > @@ -254,7 +254,7 @@ static int locomokbd_probe(struct locomo_dev *dev)
> > > > locomokbd->suspend_jiffies = jiffies;
> > > >
> > > > locomokbd->input = input_dev;
> > > > - strcpy(locomokbd->phys, "locomokbd/input0");
> > > > + strscpy(locomokbd->phys, "locomokbd/input0", sizeof(locomokbd->phys));
> > >
> > > So if the string doesn't fit, it's fine to silently truncate it?
> >
> > I think it is better than overflow :)
> >
> > > Rather than converting every single strcpy() in the kernel to
> > > strscpy(), maybe there should be some consideration given to how the
> > > issue of a strcpy() that overflows the buffer should be handled.
> > > E.g. in the case of a known string such as the above, if it's longer
> > > than the destination, should we find a way to make the compiler issue
> > > a warning at compile time?
> >
> > Good point. I am a kernel newbie and have no experience. So this
> > question should be answered by some kernel hacker :) But I agree
> > with your proposals.
> >
> > Kees and folks: Any comments?
> >
> > Note: Kees is asked the same question in [2]
> >
> > [2] https://lore.kernel.org/lkml/20210731135957.GB1979@titan/
>
> Hi!
>
> Sorry for the delay at looking into this. It didn't use to be a problem
> (there would always have been a compile-time warning generated for
> known-too-small cases), but that appears to have regressed when,
> ironically, strscpy() coverage was added. I've detailed it in the bug
> report:
> https://github.com/KSPP/linux/issues/88
>
> So, bottom line: we need to fix the missing compile-time warnings for
> strcpy() and strscpy() under CONFIG_FORTIFY_SOURCE=y.
I've got these fixed now, and will send them out likely tomorrow, but I
did, in fact, find 4 cases of truncation, all in v4l, and all appear to
have been truncated since introduction:
struct v4l2_capability {
...
__u8 card[32];
(stores 31 characters)
drivers/media/radio/radio-wl1273.c:1282
wl1273_fm_vidioc_querycap()
strscpy(capability->card, "Texas Instruments Wl1273 FM Radio",
sizeof(capability->card));
33 characters, getting truncated to:
Texas Instruments Wl1273 FM Rad
87d1a50ce45168cbaec10397e876286a398052c1
drivers/media/radio/si470x/radio-si470x-usb.c:514
si470x_vidioc_querycap()
#define DRIVER_CARD "Silicon Labs Si470x FM Radio Receiver"
strscpy(capability->card, DRIVER_CARD,
sizeof(capability->card));
37 characters, getting truncated to:
Silicon Labs Si470x FM Radio Re
78656acdcf4852547a29e929a1b7a98d5ac65f17
drivers/media/radio/si470x/radio-si470x-i2c.c:225
si470x_vidioc_querycap()
#define DRIVER_CARD "Silicon Labs Si470x FM Radio Receiver"
strscpy(capability->card, DRIVER_CARD,
sizeof(capability->card));
37 characters, getting truncated to:
Silicon Labs Si470x FM Radio Re
cc35bbddfe10f77d949f0190764b252cd2b70c3c
drivers/media/usb/tm6000/tm6000-video.c:855
vidioc_querycap()
strscpy(cap->card, "Trident TVMaster TM5600/6000/6010",
sizeof(cap->card));
33 characters, getting truncated to:
Trident TVMaster TM5600/6000/60
e28f49b0b2a8e678af62745ffdc4e4f36d7283a6
How should these be handled? I assume v4l2_capability::card can't be
resized since it's part of IOCTL response, so likely all the string just
need to be shortened in some way? Seems like dropping the manufacturer
name makes the most sense, since manufacturer can be kind of derived
from the driver names.
Thoughts?
-Kees
--
Kees Cook
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH] drivers/input: Remove all strcpy() uses in favor of strscpy()
2021-08-03 7:07 ` Kees Cook
@ 2021-08-03 7:18 ` Hans Verkuil
0 siblings, 0 replies; 16+ messages in thread
From: Hans Verkuil @ 2021-08-03 7:18 UTC (permalink / raw)
To: Kees Cook, Len Baker
Cc: Russell King (Oracle),
Dmitry Torokhov, Lee Jones, Uwe Kleine-König,
linux-hardening, linux-input, linux-kernel, Joe Perches,
Mauro Carvalho Chehab, linux-media
On 03/08/2021 09:07, Kees Cook wrote:
> On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote:
>> On Sun, Aug 01, 2021 at 05:57:32PM +0200, Len Baker wrote:
>>> Hi,
>>>
>>> On Sun, Aug 01, 2021 at 04:00:00PM +0100, Russell King (Oracle) wrote:
>>>> On Sun, Aug 01, 2021 at 04:43:16PM +0200, Len Baker wrote:
>>>>> strcpy() performs no bounds checking on the destination buffer. This
>>>>> could result in linear overflows beyond the end of the buffer, leading
>>>>> to all kinds of misbehaviors. The safe replacement is strscpy().
>>>>>
>>>>> Signed-off-by: Len Baker <len.baker@gmx.com>
>>>>> ---
>>>>> This is a task of the KSPP [1]
>>>>>
>>>>> [1] https://github.com/KSPP/linux/issues/88
>>>>>
>>>>> drivers/input/keyboard/locomokbd.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/input/keyboard/locomokbd.c b/drivers/input/keyboard/locomokbd.c
>>>>> index dae053596572..dbb3dc48df12 100644
>>>>> --- a/drivers/input/keyboard/locomokbd.c
>>>>> +++ b/drivers/input/keyboard/locomokbd.c
>>>>> @@ -254,7 +254,7 @@ static int locomokbd_probe(struct locomo_dev *dev)
>>>>> locomokbd->suspend_jiffies = jiffies;
>>>>>
>>>>> locomokbd->input = input_dev;
>>>>> - strcpy(locomokbd->phys, "locomokbd/input0");
>>>>> + strscpy(locomokbd->phys, "locomokbd/input0", sizeof(locomokbd->phys));
>>>>
>>>> So if the string doesn't fit, it's fine to silently truncate it?
>>>
>>> I think it is better than overflow :)
>>>
>>>> Rather than converting every single strcpy() in the kernel to
>>>> strscpy(), maybe there should be some consideration given to how the
>>>> issue of a strcpy() that overflows the buffer should be handled.
>>>> E.g. in the case of a known string such as the above, if it's longer
>>>> than the destination, should we find a way to make the compiler issue
>>>> a warning at compile time?
>>>
>>> Good point. I am a kernel newbie and have no experience. So this
>>> question should be answered by some kernel hacker :) But I agree
>>> with your proposals.
>>>
>>> Kees and folks: Any comments?
>>>
>>> Note: Kees is asked the same question in [2]
>>>
>>> [2] https://lore.kernel.org/lkml/20210731135957.GB1979@titan/
>>
>> Hi!
>>
>> Sorry for the delay at looking into this. It didn't use to be a problem
>> (there would always have been a compile-time warning generated for
>> known-too-small cases), but that appears to have regressed when,
>> ironically, strscpy() coverage was added. I've detailed it in the bug
>> report:
>> https://github.com/KSPP/linux/issues/88
>>
>> So, bottom line: we need to fix the missing compile-time warnings for
>> strcpy() and strscpy() under CONFIG_FORTIFY_SOURCE=y.
>
> I've got these fixed now, and will send them out likely tomorrow, but I
> did, in fact, find 4 cases of truncation, all in v4l, and all appear to
> have been truncated since introduction:
>
> struct v4l2_capability {
> ...
> __u8 card[32];
> (stores 31 characters)
>
> drivers/media/radio/radio-wl1273.c:1282
> wl1273_fm_vidioc_querycap()
> strscpy(capability->card, "Texas Instruments Wl1273 FM Radio",
> sizeof(capability->card));
> 33 characters, getting truncated to:
> Texas Instruments Wl1273 FM Rad
> 87d1a50ce45168cbaec10397e876286a398052c1
I'd change this to: "TI WL1273 FM Radio"
>
> drivers/media/radio/si470x/radio-si470x-usb.c:514
> si470x_vidioc_querycap()
> #define DRIVER_CARD "Silicon Labs Si470x FM Radio Receiver"
> strscpy(capability->card, DRIVER_CARD,
> sizeof(capability->card));
> 37 characters, getting truncated to:
> Silicon Labs Si470x FM Radio Re
> 78656acdcf4852547a29e929a1b7a98d5ac65f17
This to "Silicon Labs Si470x FM Radio"
>
> drivers/media/radio/si470x/radio-si470x-i2c.c:225
> si470x_vidioc_querycap()
> #define DRIVER_CARD "Silicon Labs Si470x FM Radio Receiver"
> strscpy(capability->card, DRIVER_CARD,
> sizeof(capability->card));
> 37 characters, getting truncated to:
> Silicon Labs Si470x FM Radio Re
> cc35bbddfe10f77d949f0190764b252cd2b70c3c
Ditto.
>
> drivers/media/usb/tm6000/tm6000-video.c:855
> vidioc_querycap()
> strscpy(cap->card, "Trident TVMaster TM5600/6000/6010",
> sizeof(cap->card));
> 33 characters, getting truncated to:
> Trident TVMaster TM5600/6000/60
> e28f49b0b2a8e678af62745ffdc4e4f36d7283a6
And this to: "Trident TM5600/6000/6010"
The truncation doesn't hurt anything, it's just looks a bit ugly.
These shorter names should solve this issue.
Regards,
Hans
>
> How should these be handled? I assume v4l2_capability::card can't be
> resized since it's part of IOCTL response, so likely all the string just
> need to be shortened in some way? Seems like dropping the manufacturer
> name makes the most sense, since manufacturer can be kind of derived
> from the driver names.
>
> Thoughts?
>
> -Kees
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] drivers/input: Remove all strcpy() uses in favor of strscpy()
2021-08-01 16:44 ` Kees Cook
2021-08-01 17:19 ` Dmitry Torokhov
2021-08-03 7:07 ` Kees Cook
@ 2021-08-07 14:02 ` Len Baker
2021-08-07 15:17 ` Joe Perches
2 siblings, 1 reply; 16+ messages in thread
From: Len Baker @ 2021-08-07 14:02 UTC (permalink / raw)
To: Kees Cook
Cc: Len Baker, Russell King (Oracle),
Dmitry Torokhov, Lee Jones, Uwe Kleine-König,
linux-hardening, linux-input, linux-kernel, Joe Perches
Hi,
On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote:
> On Sun, Aug 01, 2021 at 05:57:32PM +0200, Len Baker wrote:
> > Hi,
> >
> > On Sun, Aug 01, 2021 at 04:00:00PM +0100, Russell King (Oracle) wrote:
> > > Rather than converting every single strcpy() in the kernel to
> > > strscpy(), maybe there should be some consideration given to how the
> > > issue of a strcpy() that overflows the buffer should be handled.
> > > E.g. in the case of a known string such as the above, if it's longer
> > > than the destination, should we find a way to make the compiler issue
> > > a warning at compile time?
> >
> > Good point. I am a kernel newbie and have no experience. So this
> > question should be answered by some kernel hacker :) But I agree
> > with your proposals.
> >
> > Kees and folks: Any comments?
> >
> > Note: Kees is asked the same question in [2]
> >
> > [2] https://lore.kernel.org/lkml/20210731135957.GB1979@titan/
>
> Hi!
>
> Sorry for the delay at looking into this. It didn't use to be a problem
> (there would always have been a compile-time warning generated for
> known-too-small cases), but that appears to have regressed when,
> ironically, strscpy() coverage was added. I've detailed it in the bug
> report:
> https://github.com/KSPP/linux/issues/88
>
> So, bottom line: we need to fix the missing compile-time warnings for
> strcpy() and strscpy() under CONFIG_FORTIFY_SOURCE=y.
>
> In the past we'd tried to add a stracpy()[1] that would only work with
> const string sources. Linus got angry[2] about API explosion, though,
> so we're mostly faced with doing the strscpy() replacements.
>
> Another idea might be to have strcpy() do the "constant strings only"
> thing, leaving strscpy() for the dynamic lengths.
>
> One thing is clear: replacing strlcpy() with strscpy() is probably the
> easiest and best first step to cleaning up the proliferation of str*()
> functions.
Thanks for all this info. I will work on it (clean up the proliferation
of str*() functions).
Regards,
Len
>
> -Kees
>
> [1] https://lore.kernel.org/lkml/ed4611a4a96057bf8076856560bfbf9b5e95d390.1563889130.git.joe@perches.com/
> [2] https://lore.kernel.org/lkml/CAHk-=wgqQKoAnhmhGE-2PBFt7oQs9LLAATKbYa573UO=DPBE0Q@mail.gmail.com/
>
> --
> Kees Cook
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] drivers/input: Remove all strcpy() uses in favor of strscpy()
2021-08-07 14:02 ` Len Baker
@ 2021-08-07 15:17 ` Joe Perches
2021-08-08 11:30 ` Len Baker
0 siblings, 1 reply; 16+ messages in thread
From: Joe Perches @ 2021-08-07 15:17 UTC (permalink / raw)
To: Len Baker, Kees Cook
Cc: Russell King (Oracle),
Dmitry Torokhov, Lee Jones, Uwe Kleine-König,
linux-hardening, linux-input, linux-kernel
On Sat, 2021-08-07 at 16:02 +0200, Len Baker wrote:
> On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote:
[]
> > One thing is clear: replacing strlcpy() with strscpy() is probably the
> > easiest and best first step to cleaning up the proliferation of str*()
> > functions.
>
> Thanks for all this info. I will work on it (clean up the proliferation
> of str*() functions).
btw:
It's not possible to sed as the return value is different,
but here is a cocci script that converts strlcpy to strscpy
when the return value is unused.
@@
expression e1, e2, e3;
@@
- strlcpy(
+ strscpy(
e1, e2, e3);
This cocci script was used on sound/ awhile back.
see commit 75b1a8f9d62e.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH] drivers/input: Remove all strcpy() uses in favor of strscpy()
2021-08-07 15:17 ` Joe Perches
@ 2021-08-08 11:30 ` Len Baker
0 siblings, 0 replies; 16+ messages in thread
From: Len Baker @ 2021-08-08 11:30 UTC (permalink / raw)
To: Joe Perches
Cc: Len Baker, Kees Cook, Russell King (Oracle),
Dmitry Torokhov, Lee Jones, Uwe Kleine-König,
linux-hardening, linux-input, linux-kernel
Hi,
On Sat, Aug 07, 2021 at 08:17:39AM -0700, Joe Perches wrote:
> On Sat, 2021-08-07 at 16:02 +0200, Len Baker wrote:
> > On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote:
> []
> > > One thing is clear: replacing strlcpy() with strscpy() is probably the
> > > easiest and best first step to cleaning up the proliferation of str*()
> > > functions.
> >
> > Thanks for all this info. I will work on it (clean up the proliferation
> > of str*() functions).
>
> btw:
>
> It's not possible to sed as the return value is different,
> but here is a cocci script that converts strlcpy to strscpy
> when the return value is unused.
>
> @@
> expression e1, e2, e3;
> @@
>
> - strlcpy(
> + strscpy(
> e1, e2, e3);
>
> This cocci script was used on sound/ awhile back.
> see commit 75b1a8f9d62e.
Thanks a lot for your help on this. I will take into account all this info.
Regards,
Len
^ permalink raw reply [flat|nested] 16+ messages in thread