aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/bpf/prog_tests/stacktrace_map.c
diff options
context:
space:
mode:
authorAndrii Nakryiko <[email protected]>2021-12-11 00:40:43 +0000
committerDaniel Borkmann <[email protected]>2021-12-14 14:47:56 +0000
commit9fc205b413b3f3e9502fa92151fba63b91230454 (patch)
tree9964b204c6a1721168b7041e060df59b5123ce7a /tools/testing/selftests/bpf/prog_tests/stacktrace_map.c
parentlibbpf: Fix potential uninit memory read (diff)
downloadkernel-9fc205b413b3f3e9502fa92151fba63b91230454.tar.gz
kernel-9fc205b413b3f3e9502fa92151fba63b91230454.zip
libbpf: Add sane strncpy alternative and use it internally
strncpy() has a notoriously error-prone semantics which makes GCC complain about it a lot (and quite often completely completely falsely at that). Instead of pleasing GCC all the time (-Wno-stringop-truncation is unfortunately only supported by GCC, so it's a bit too messy to just enable it in Makefile), add libbpf-internal libbpf_strlcpy() helper which follows what FreeBSD's strlcpy() does and what most people would expect from strncpy(): copies up to N-1 first bytes from source string into destination string and ensures zero-termination afterwards. Replace all the relevant uses of strncpy/strncat/memcpy in libbpf with libbpf_strlcpy(). This also fixes the issue reported by Emmanuel Deloget in xsk.c where memcpy() could access source string beyond its end. Fixes: 2f6324a3937f8 (libbpf: Support shared umems between queues and devices) Reported-by: Emmanuel Deloget <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
Diffstat (limited to 'tools/testing/selftests/bpf/prog_tests/stacktrace_map.c')
0 files changed, 0 insertions, 0 deletions