[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190531131321.GB1281@krava>
Date: Fri, 31 May 2019 15:13:21 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Jiri Olsa <jolsa@...nel.org>, Ben Gainey <ben.gainey@....com>,
Stephane Eranian <eranian@...gle.com>,
lkml <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: [PATCHv2] perf jvmti: Fix gcc string overflow warning
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@....com>
Cc: Stephane Eranian <eranian@...gle.com>
Suggested-by: Arnaldo Carvalho de Melo <acme@...hat.com>
Link: http://lkml.kernel.org/n/tip-sve3b63c550wr907e6ui6gx5@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@...nel.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
Powered by blists - more mailing lists