From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>, Ben Gainey <ben.gainey@arm.com>,
Stephane Eranian <eranian@google.com>,
lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: [PATCHv2] perf jvmti: Fix gcc string overflow warning
Date: Fri, 31 May 2019 15:13:21 +0200 [thread overview]
Message-ID: <20190531131321.GB1281@krava> (raw)
In-Reply-To: <20190531120530.GB17152@kernel.org>
On Fri, May 31, 2019 at 09:05:30AM -0300, Arnaldo Carvalho de Melo wrote:
SNIP
> The kernel folks moved beyond that and in lib/string.c we have:
>
> /**
> * strscpy - Copy a C-string into a sized buffer
> * @dest: Where to copy the string to
> * @src: Where to copy the string from
> * @count: Size of destination buffer
> *
> * Copy the string, or as much of it as fits, into the dest buffer. The
> * behavior is undefined if the string buffers overlap. The destination
> * buffer is always NUL terminated, unless it's zero-sized.
> *
> * Preferred to strlcpy() since the API doesn't require reading memory
> * from the src string beyond the specified "count" bytes, and since
> * the return value is easier to error-check than strlcpy()'s.
> * In addition, the implementation is robust to the string changing out
> * from underneath it, unlike the current strlcpy() implementation.
> *
> * Preferred to strncpy() since it always returns a valid string, and
> * doesn't unnecessarily force the tail of the destination buffer to be
> * zeroed. If zeroing is desired please use strscpy_pad().
> *
> * Return: The number of characters copied (not including the trailing
> * %NUL) or -E2BIG if the destination buffer wasn't big enough.
> */
> ssize_t strscpy(char *dest, const char *src, size_t count)
>
>
>
> I think for these needs flipping that 'n' into a 'l' is good enough.
ok, I forgot there's strlcpy.. v2 attached
thanks,
jirka
---
We are getting fake gcc warning when we compile with gcc9 (9.1.1):
CC jvmti/libjvmti.o
In file included from /usr/include/string.h:494,
from jvmti/libjvmti.c:5:
In function ‘strncpy’,
inlined from ‘copy_class_filename.constprop’ at jvmti/libjvmti.c:166:3:
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jvmti/libjvmti.c: In function ‘copy_class_filename.constprop’:
jvmti/libjvmti.c:165:26: note: length computed here
165 | size_t file_name_len = strlen(file_name);
| ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
As per Arnaldo's suggestion using strlcpy, which does
the same thing and keeps gcc silent.
Cc: Ben Gainey <ben.gainey@arm.com>
Cc: Stephane Eranian <eranian@google.com>
Suggested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: http://lkml.kernel.org/n/tip-sve3b63c550wr907e6ui6gx5@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/perf/jvmti/libjvmti.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/jvmti/libjvmti.c b/tools/perf/jvmti/libjvmti.c
index aea7b1fe85aa..c441a34cb1c0 100644
--- a/tools/perf/jvmti/libjvmti.c
+++ b/tools/perf/jvmti/libjvmti.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/compiler.h>
+#include <linux/string.h>
#include <sys/types.h>
#include <stdio.h>
#include <string.h>
@@ -162,8 +163,7 @@ copy_class_filename(const char * class_sign, const char * file_name, char * resu
result[i] = '\0';
} else {
/* fallback case */
- size_t file_name_len = strlen(file_name);
- strncpy(result, file_name, file_name_len < max_length ? file_name_len : max_length);
+ strlcpy(result, file_name, max_length);
}
}
--
2.21.0
next prev parent reply other threads:[~2019-05-31 13:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 8:03 [PATCH] perf jvmti: Fix gcc string overflow warning Jiri Olsa
2019-05-31 12:05 ` Arnaldo Carvalho de Melo
2019-05-31 13:13 ` Jiri Olsa [this message]
2019-06-05 12:53 ` [PATCHv2] " Arnaldo Carvalho de Melo
2019-06-17 19:15 ` [tip:perf/core] perf jvmti: Address gcc string overflow warning for strncpy() tip-bot for Jiri Olsa
2019-07-09 11:33 ` tip-bot for Jiri Olsa
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=20190531131321.GB1281@krava \
--to=jolsa@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=ben.gainey@arm.com \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox