strlcpy() copy a C-String into a sized buffer, the result is always a
valid NULL-terminated that fits in the buffer, howerver it has severals
issues. It reads the source buffer first, which is dangerous if it is non
NULL-terminated or if the corresponding buffer is unbounded. Its safe
replacement is strscpy(), as suggested in the deprecated interface [1].
We plan to make this contribution in two steps:
- Firsly all cases of strlcpy's return value are manually replaced by the
corresponding calls of strscpy() with the new handling of the return
value (as the return code is different in case of error).
- Then all other cases are automatically replaced by using coccinelle.
This series covers manual replacements.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
Romain Perier (20):
cgroup: Manual replacement of the deprecated strlcpy() with return
values
crypto: Manual replacement of the deprecated strlcpy() with return
values
devlink: Manual replacement of the deprecated strlcpy() with return
values
dma-buf: Manual replacement of the deprecated strlcpy() with return
values
kobject: Manual replacement of the deprecated strlcpy() with return
values
ima: Manual replacement of the deprecated strlcpy() with return values
SUNRPC: Manual replacement of the deprecated strlcpy() with return
values
kernfs: Manual replacement of the deprecated strlcpy() with return
values
m68k/atari: Manual replacement of the deprecated strlcpy() with return
values
module: Manual replacement of the deprecated strlcpy() with return
values
hwmon: Manual replacement of the deprecated strlcpy() with return
values
s390/hmcdrv: Manual replacement of the deprecated strlcpy() with
return values
scsi: zfcp: Manual replacement of the deprecated strlcpy() with return
values
target: Manual replacement of the deprecated strlcpy() with return
values
ALSA: usb-audio: Manual replacement of the deprecated strlcpy() with
return values
tracing/probe: Manual replacement of the deprecated strlcpy() with
return values
vt: Manual replacement of the deprecated strlcpy() with return values
usb: gadget: f_midi: Manual replacement of the deprecated strlcpy()
with return values
usbip: usbip_host: Manual replacement of the deprecated strlcpy() with
return values
s390/watchdog: Manual replacement of the deprecated strlcpy() with
return values
arch/m68k/emu/natfeat.c | 6 +--
crypto/lrw.c | 6 +--
crypto/xts.c | 6 +--
drivers/dma-buf/dma-buf.c | 4 +-
drivers/hwmon/pmbus/max20730.c | 66 +++++++++++++------------
drivers/s390/char/diag_ftp.c | 4 +-
drivers/s390/char/sclp_ftp.c | 6 +--
drivers/s390/scsi/zfcp_fc.c | 8 +--
drivers/target/target_core_configfs.c | 33 ++++---------
drivers/tty/vt/keyboard.c | 5 +-
drivers/usb/gadget/function/f_midi.c | 4 +-
drivers/usb/gadget/function/f_printer.c | 8 +--
drivers/usb/usbip/stub_main.c | 6 +--
drivers/watchdog/diag288_wdt.c | 12 +++--
fs/kernfs/dir.c | 27 +++++-----
kernel/cgroup/cgroup.c | 2 +-
kernel/module.c | 4 +-
kernel/trace/trace_uprobe.c | 11 ++---
lib/kobject_uevent.c | 6 +--
net/core/devlink.c | 6 +--
net/sunrpc/clnt.c | 6 ++-
security/integrity/ima/ima_policy.c | 8 ++-
sound/usb/card.c | 4 +-
23 files changed, 129 insertions(+), 119 deletions(-)
--
2.20.1
The strlcpy() reads the entire source buffer first, it is dangerous if
the source buffer lenght is unbounded or possibility non NULL-terminated.
It can lead to linear read overflows, crashes, etc...
As recommended in the deprecated interfaces [1], it should be replaced
by strscpy.
This commit replaces all calls to strlcpy that handle the return values
by the corresponding strscpy calls with new handling of the return
values (as it is quite different between the two functions).
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
drivers/usb/usbip/stub_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
The strlcpy() reads the entire source buffer first, it is dangerous if
the source buffer lenght is unbounded or possibility non NULL-terminated.
It can lead to linear read overflows, crashes, etc...
As recommended in the deprecated interfaces [1], it should be replaced
by strscpy.
This commit replaces all calls to strlcpy that handle the return values
by the corresponding strscpy calls with new handling of the return
values (as it is quite different between the two functions).
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
drivers/usb/gadget/function/f_midi.c | 4 ++--
drivers/usb/gadget/function/f_printer.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
The strlcpy() reads the entire source buffer first, it is dangerous if
the source buffer lenght is unbounded or possibility non NULL-terminated.
It can lead to linear read overflows, crashes, etc...
As recommended in the deprecated interfaces [1], it should be replaced
by strscpy.
This commit replaces all calls to strlcpy that handle the return values
by the corresponding strscpy calls with new handling of the return
values (as it is quite different between the two functions).
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
drivers/usb/usbip/stub_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
strlcpy() copy a C-String into a sized buffer, the result is always a
valid NULL-terminated that fits in the buffer, howerver it has severals
issues. It reads the source buffer first, which is dangerous if it is non
NULL-terminated or if the corresponding buffer is unbounded. Its safe
replacement is strscpy(), as suggested in the deprecated interface [1].
We plan to make this contribution in two steps:
- Firsly all cases of strlcpy's return value are manually replaced by the
corresponding calls of strscpy() with the new handling of the return
value (as the return code is different in case of error).
- Then all other cases are automatically replaced by using coccinelle.
Cool. A quick check shows me 1031 strscpy() calls with no return
checks. All or some of these probably need to be reviewed and add
return checks. Is this something that is in the plan to address as
part of this work?
thanks,
-- Shuah
From: Sergei Shtylyov <hidden> Date: 2021-02-28 09:05:02
Hello!
On 22.02.2021 18:12, Romain Perier wrote:
The strlcpy() reads the entire source buffer first, it is dangerous if
the source buffer lenght is unbounded or possibility non NULL-terminated.
Length. Possibly?
It can lead to linear read overflows, crashes, etc...
As recommended in the deprecated interfaces [1], it should be replaced
by strscpy.
This commit replaces all calls to strlcpy that handle the return values
by the corresponding strscpy calls with new handling of the return
values (as it is quite different between the two functions).
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
Signed-off-by: Romain Perier <romain.perier@gmail.com>