On Wed, Aug 26, 2020 at 07:42:17PM -0700, Joe Perches wrote:
On Wed, 2020-08-26 at 19:33 -0700, Kees Cook wrote:
On Wed, Aug 26, 2020 at 04:57:41PM -0700, Joe Perches wrote:
On Wed, 2020-08-26 at 16:38 -0700, Kees Cook wrote:
On Thu, Aug 27, 2020 at 07:59:45AM +0900, Masahiro Yamada wrote:
[]
OK, then stpcpy(), strcpy() and sprintf() have the same level of unsafety.
Yes. And even snprintf() is dangerous because its return value is how much it WOULD have written, which when (commonly) used as an offset for further pointer writes, causes OOB writes too. :( https://github.com/KSPP/linux/issues/105
strcpy() is used everywhere.
Yes. It's very frustrating, but it's not an excuse to continue using it nor introducing more bad APIs.
$ git grep '\bstrcpy\b' | wc -l 2212 $ git grep '\bstrncpy\b' | wc -l 751 $ git grep '\bstrlcpy\b' | wc -l 1712
$ git grep '\bstrscpy\b' | wc -l 1066
https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy https://github.com/KSPP/linux/issues/88
https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nu... https://github.com/KSPP/linux/issues/89
https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy https://github.com/KSPP/linux/issues/90
We have no way right now to block the addition of deprecated API usage, which makes ever catching up on this replacement very challenging.
These could be added to checkpatch's deprecated_api test.
scripts/checkpatch.pl | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 149518d2a6a7..f9ccb2a63a95 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -605,6 +605,9 @@ foreach my $entry (@mode_permission_funcs) { $mode_perms_search = "(?:${mode_perms_search})"; our %deprecated_apis = (
- "strcpy" => "strscpy",
- "strncpy" => "strscpy",
- "strlcpy" => "strscpy", "synchronize_rcu_bh" => "synchronize_rcu", "synchronize_rcu_bh_expedited" => "synchronize_rcu_expedited", "call_rcu_bh" => "call_rcu",
Good idea, yeah. We, unfortunately, need to leave strncpy() off this list for now because it's not *strictly* deprecated (see the notes in bug report[1]), but the others can be.
OK, but it is in Documentation/process/deprecated.rst
strncpy() on NUL-terminated strings
"... on NUL-terminated strings". It's "valid" to use it on known-size (either external or by definition) NUL-padded buffers (e.g. NLA_STRING).