May 2022 - Linux-kselftest-mirror

[PATCH AUTOSEL 5.10 04/13] selftests: add ping test with ping_group_range tuned

by Sasha Levin

From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> [ Upstream commit e71b7f1f44d3d88c677769c85ef0171caf9fc89f ] The 'ping' utility is able to manage two kind of sockets (raw or icmp), depending on the sysctl ping_group_range. By default, ping_group_range is set to '1 0', which forces ping to use an ip raw socket. Let's replay the ping tests by allowing 'ping' to use the ip icmp socket. After the previous patch, ipv4 tests results are the same with both kinds of socket. For ipv6, there are a lot a new failures (the previous patch fixes only two cases). Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/net/fcnal-test.sh | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/tools/testing/selftests/net/fcnal-test.sh b/tools/testing/selftests/net/fcnal-test.sh index ace976d89125..4a11ea2261cb 100755 --- a/tools/testing/selftests/net/fcnal-test.sh +++ b/tools/testing/selftests/net/fcnal-test.sh @@ -794,10 +794,16 @@ ipv4_ping() setup set_sysctl net.ipv4.raw_l3mdev_accept=1 2>/dev/null ipv4_ping_novrf + setup + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv4_ping_novrf log_subsection "With VRF" setup "yes" ipv4_ping_vrf + setup "yes" + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv4_ping_vrf } ################################################################################ @@ -2261,10 +2267,16 @@ ipv6_ping() log_subsection "No VRF" setup ipv6_ping_novrf + setup + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv6_ping_novrf log_subsection "With VRF" setup "yes" ipv6_ping_vrf + setup "yes" + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv6_ping_vrf } ################################################################################ -- 2.35.1

2 years, 7 months

1
0
0 0

[PATCH AUTOSEL 5.15 05/17] selftests: add ping test with ping_group_range tuned

by Sasha Levin

From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> [ Upstream commit e71b7f1f44d3d88c677769c85ef0171caf9fc89f ] The 'ping' utility is able to manage two kind of sockets (raw or icmp), depending on the sysctl ping_group_range. By default, ping_group_range is set to '1 0', which forces ping to use an ip raw socket. Let's replay the ping tests by allowing 'ping' to use the ip icmp socket. After the previous patch, ipv4 tests results are the same with both kinds of socket. For ipv6, there are a lot a new failures (the previous patch fixes only two cases). Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/net/fcnal-test.sh | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/tools/testing/selftests/net/fcnal-test.sh b/tools/testing/selftests/net/fcnal-test.sh index aec9e784d0b4..91f54112167f 100755 --- a/tools/testing/selftests/net/fcnal-test.sh +++ b/tools/testing/selftests/net/fcnal-test.sh @@ -803,10 +803,16 @@ ipv4_ping() setup set_sysctl net.ipv4.raw_l3mdev_accept=1 2>/dev/null ipv4_ping_novrf + setup + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv4_ping_novrf log_subsection "With VRF" setup "yes" ipv4_ping_vrf + setup "yes" + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv4_ping_vrf } ################################################################################ @@ -2324,10 +2330,16 @@ ipv6_ping() log_subsection "No VRF" setup ipv6_ping_novrf + setup + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv6_ping_novrf log_subsection "With VRF" setup "yes" ipv6_ping_vrf + setup "yes" + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv6_ping_vrf } ################################################################################ -- 2.35.1

2 years, 7 months

1
0
0 0

[PATCH AUTOSEL 5.17 06/23] selftests: add ping test with ping_group_range tuned

by Sasha Levin

From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> [ Upstream commit e71b7f1f44d3d88c677769c85ef0171caf9fc89f ] The 'ping' utility is able to manage two kind of sockets (raw or icmp), depending on the sysctl ping_group_range. By default, ping_group_range is set to '1 0', which forces ping to use an ip raw socket. Let's replay the ping tests by allowing 'ping' to use the ip icmp socket. After the previous patch, ipv4 tests results are the same with both kinds of socket. For ipv6, there are a lot a new failures (the previous patch fixes only two cases). Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/net/fcnal-test.sh | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/tools/testing/selftests/net/fcnal-test.sh b/tools/testing/selftests/net/fcnal-test.sh index 3f4c8cfe7aca..7cd9b31d0307 100755 --- a/tools/testing/selftests/net/fcnal-test.sh +++ b/tools/testing/selftests/net/fcnal-test.sh @@ -810,10 +810,16 @@ ipv4_ping() setup set_sysctl net.ipv4.raw_l3mdev_accept=1 2>/dev/null ipv4_ping_novrf + setup + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv4_ping_novrf log_subsection "With VRF" setup "yes" ipv4_ping_vrf + setup "yes" + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv4_ping_vrf } ################################################################################ @@ -2348,10 +2354,16 @@ ipv6_ping() log_subsection "No VRF" setup ipv6_ping_novrf + setup + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv6_ping_novrf log_subsection "With VRF" setup "yes" ipv6_ping_vrf + setup "yes" + set_sysctl net.ipv4.ping_group_range='0 2147483647' 2>/dev/null + ipv6_ping_vrf } ################################################################################ -- 2.35.1

2 years, 7 months

1
0
0 0

[PATCH] selftests/lkdtm: add config

by Muhammad Usama Anjum

Add config options which are needed for LKDTM sub-tests. STACKLEAK_ERASING test needs GCC_PLUGIN_STACKLEAK config. READ_AFTER_FREE and READ_BUDDY_AFTER_FREE tests need INIT_ON_FREE_DEFAULT_ON config. Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- tools/testing/selftests/lkdtm/config | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/lkdtm/config b/tools/testing/selftests/lkdtm/config index 3041236887394..5d52f64dfb430 100644 --- a/tools/testing/selftests/lkdtm/config +++ b/tools/testing/selftests/lkdtm/config @@ -2,8 +2,10 @@ CONFIG_LKDTM=y CONFIG_DEBUG_LIST=y CONFIG_SLAB_FREELIST_HARDENED=y CONFIG_FORTIFY_SOURCE=y +CONFIG_GCC_PLUGIN_STACKLEAK=y CONFIG_HARDENED_USERCOPY=y CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y +CONFIG_INIT_ON_FREE_DEFAULT_ON=y CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y CONFIG_UBSAN=y CONFIG_UBSAN_BOUNDS=y -- 2.30.2

2 years, 7 months

2
1
0 0

[PATCH] kunit: Taint kernel if any tests run

by David Gow

KUnit tests are not supposed to run on production systems: they may do deliberately illegal things to trigger errors, and have security implications (assertions will often deliberately leak kernel addresses). Add a new taint type, TAINT_KUNIT to signal that a KUnit test has been run. This will be printed as 'N' (for kuNit, as K, U and T were already taken). This should discourage people from running KUnit tests on production systems, and to make it easier to tell if tests have been run accidentally (by loading the wrong configuration, etc.) Signed-off-by: David Gow <davidgow(a)google.com> --- This is something I'd been thinking about for a while, and it came up again, so I'm finally giving it a go. Two notes: - I decided to add a new type of taint, as none of the existing ones really seemed to fit. We could live with considering KUnit tests as TAINT_WARN or TAINT_CRAP or something otherwise, but neither are quite right. - The taint_flags table gives a couple of checkpatch.pl errors around bracket placement. I've kept the new entry consistent with what's there rather than reformatting the whole table, but be prepared for complaints about spaces. Thoughts? -- David --- Documentation/admin-guide/tainted-kernels.rst | 1 + include/linux/panic.h | 3 ++- kernel/panic.c | 1 + lib/kunit/test.c | 4 ++++ 4 files changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index ceeed7b0798d..8f18fc4659d4 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -100,6 +100,7 @@ Bit Log Number Reason that got the kernel tainted 15 _/K 32768 kernel has been live patched 16 _/X 65536 auxiliary taint, defined for and used by distros 17 _/T 131072 kernel was built with the struct randomization plugin + 18 _/N 262144 a KUnit test has been run === === ====== ======================================================== Note: The character ``_`` is representing a blank in this table to make reading diff --git a/include/linux/panic.h b/include/linux/panic.h index f5844908a089..1d316c26bf27 100644 --- a/include/linux/panic.h +++ b/include/linux/panic.h @@ -74,7 +74,8 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout) #define TAINT_LIVEPATCH 15 #define TAINT_AUX 16 #define TAINT_RANDSTRUCT 17 -#define TAINT_FLAGS_COUNT 18 +#define TAINT_KUNIT 18 +#define TAINT_FLAGS_COUNT 19 #define TAINT_FLAGS_MAX ((1UL << TAINT_FLAGS_COUNT) - 1) struct taint_flag { diff --git a/kernel/panic.c b/kernel/panic.c index eb4dfb932c85..b24ca63ed738 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -404,6 +404,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = { [ TAINT_LIVEPATCH ] = { 'K', ' ', true }, [ TAINT_AUX ] = { 'X', ' ', true }, [ TAINT_RANDSTRUCT ] = { 'T', ' ', true }, + [ TAINT_KUNIT ] = { 'N', ' ', false }, }; /** diff --git a/lib/kunit/test.c b/lib/kunit/test.c index 0f66c13d126e..ea8e9162445d 100644 --- a/lib/kunit/test.c +++ b/lib/kunit/test.c @@ -11,6 +11,7 @@ #include <kunit/test-bug.h> #include <linux/kernel.h> #include <linux/moduleparam.h> +#include <linux/panic.h> #include <linux/sched/debug.h> #include <linux/sched.h> @@ -498,6 +499,9 @@ int kunit_run_tests(struct kunit_suite *suite) struct kunit_result_stats suite_stats = { 0 }; struct kunit_result_stats total_stats = { 0 }; + /* Taint the kernel so we know we've run tests. */ + add_taint(TAINT_KUNIT, LOCKDEP_STILL_OK); + kunit_print_subtest_start(suite); kunit_suite_for_each_test_case(suite, test_case) { -- 2.36.0.464.gb9c8b46e94-goog

2 years, 7 months

6
32
0 0

[PATCH] kunit: tool: Use qemu-system-i386 for i386 runs

by David Gow

We're currently using the x86_64 qemu for i386 builds. While this is not incorrect, it's probably more sensible to use the i386 one, which will at least fail properly if we accidentally were to build a 64-bit kernel. Signed-off-by: David Gow <davidgow(a)google.com> --- tools/testing/kunit/qemu_configs/i386.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/kunit/qemu_configs/i386.py b/tools/testing/kunit/qemu_configs/i386.py index 52b80be40e4b..4463ebefd567 100644 --- a/tools/testing/kunit/qemu_configs/i386.py +++ b/tools/testing/kunit/qemu_configs/i386.py @@ -4,7 +4,7 @@ QEMU_ARCH = QemuArchParams(linux_arch='i386', kconfig=''' CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y''', - qemu_arch='x86_64', + qemu_arch='i386', kernel_path='arch/x86/boot/bzImage', kernel_command_line='console=ttyS0', extra_qemu_params=[]) -- 2.36.0.550.gb090851708-goog

2 years, 7 months

3
3
0 0

New collaboration

by Luca Gauthier

Hello, are you looking for more business clients? We would like to start working with you as a partner in acquiring or exchanging leads, which directly translates into mutual benefits in the form of an increased client portfolio. We work in the sector of internet marketing and as one of the first in Europe SEO Agencies we’ve introduced the SEO 360 service which allows your clients to gain the access to original SEO consultations. By choosing to work with us you receive support in achieving your business goals, and help in handling Digital Marketing for your clients. We support over 237 partner companies. We have one of the biggest executive departments in Europe at our disposal, we’ve prepared over 2000 campaigns in Europe and 200 in the USA and Canada. Are you interested in the details of our partnership programme? Yours sincerely, Luca Gauthier

2 years, 7 months

1
0
0 0

[PATCH v3 0/2] Dirtying, failing memop: don't indicate suppression

by Janis Schoetterl-Glausch

If a memop fails due to key checked protection, after already having written to the guest, don't indicate suppression to the guest, as that would imply that memory wasn't modified. This could be considered a fix to the code introducing storage key support, however this is a bug in KVM only if we emulate an instructions writing to an operand spanning multiple pages, which I don't believe we do. v2 -> v3 * tweak commit message * explicitly reset the protection code to 0 on termination * use variable to pass termination arg * add documentation * fix magic constant in selftest Given the changes I did not pick up the r-b's. v1 -> v2 * Reword commit message of patch 1 Janis Schoetterl-Glausch (2): KVM: s390: Don't indicate suppression on dirtying, failing memop KVM: s390: selftest: Test suppression indication on key prot exception Documentation/virt/kvm/api.rst | 6 +++ arch/s390/kvm/gaccess.c | 22 +++++++++-- tools/testing/selftests/kvm/s390x/memop.c | 46 ++++++++++++++++++++++- 3 files changed, 69 insertions(+), 5 deletions(-) Range-diff against v2: 1: b5725a836f1a ! 1: e1dae6522b22 KVM: s390: Don't indicate suppression on dirtying, failing memop @@ Commit message Instruction execution can end in different ways, one of which is suppression, which requires that the instruction execute like a no-op. A writing memop that spans multiple pages and fails due to key - protection can modified guest memory, as a result, the likely - correct ending is termination. Therefore do not indicate a + protection may have modified guest memory, as a result, the likely + correct ending is termination. Therefore, do not indicate a suppressing instruction ending in this case. Signed-off-by: Janis Schoetterl-Glausch <scgl(a)linux.ibm.com> + ## Documentation/virt/kvm/api.rst ## +@@ Documentation/virt/kvm/api.rst: in case of KVM_S390_MEMOP_F_CHECK_ONLY), the ioctl returns a positive + error number indicating the type of exception. This exception is also + raised directly at the corresponding VCPU if the flag + KVM_S390_MEMOP_F_INJECT_EXCEPTION is set. ++On protection exceptions, unless specified otherwise, the injected ++translation-exception identifier (TEID) indicates suppression. + + If the KVM_S390_MEMOP_F_SKEY_PROTECTION flag is set, storage key + protection is also in effect and may cause exceptions if accesses are + prohibited given the access key designated by "key"; the valid range is 0..15. + KVM_S390_MEMOP_F_SKEY_PROTECTION is available if KVM_CAP_S390_MEM_OP_EXTENSION + is > 0. ++Since the accessed memory may span multiple pages and those pages might have ++different storage keys, it is possible that a protection exception occurs ++after memory has been modified. In this case, if the exception is injected, ++the TEID does not indicate suppression. + + Absolute read/write: + ^^^^^^^^^^^^^^^^^^^^ + ## arch/s390/kvm/gaccess.c ## @@ arch/s390/kvm/gaccess.c: enum prot_type { PROT_TYPE_IEP = 4, @@ arch/s390/kvm/gaccess.c: enum prot_type { -static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva, - u8 ar, enum gacc_mode mode, enum prot_type prot) +static int trans_exc_ending(struct kvm_vcpu *vcpu, int code, unsigned long gva, u8 ar, -+ enum gacc_mode mode, enum prot_type prot, bool suppress) ++ enum gacc_mode mode, enum prot_type prot, bool terminate) { struct kvm_s390_pgm_info *pgm = &vcpu->arch.pgm; struct trans_exc_code_bits *tec; @@ arch/s390/kvm/gaccess.c: static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva, - - switch (code) { - case PGM_PROTECTION: -- switch (prot) { -- case PROT_TYPE_IEP: -- tec->b61 = 1; -- fallthrough; -- case PROT_TYPE_LA: -- tec->b56 = 1; -- break; -- case PROT_TYPE_KEYC: -- tec->b60 = 1; -- break; -- case PROT_TYPE_ALC: -- tec->b60 = 1; -- fallthrough; -- case PROT_TYPE_DAT: -- tec->b61 = 1; -- break; -+ if (suppress) { -+ switch (prot) { -+ case PROT_TYPE_IEP: -+ tec->b61 = 1; -+ fallthrough; -+ case PROT_TYPE_LA: -+ tec->b56 = 1; -+ break; -+ case PROT_TYPE_KEYC: -+ tec->b60 = 1; -+ break; -+ case PROT_TYPE_ALC: -+ tec->b60 = 1; -+ fallthrough; -+ case PROT_TYPE_DAT: -+ tec->b61 = 1; -+ break; -+ } + tec->b61 = 1; + break; } ++ if (terminate) { ++ tec->b56 = 0; ++ tec->b60 = 0; ++ tec->b61 = 0; ++ } fallthrough; case PGM_ASCE_TYPE: + case PGM_PAGE_TRANSLATION: @@ arch/s390/kvm/gaccess.c: static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva, return code; } @@ arch/s390/kvm/gaccess.c: static int trans_exc(struct kvm_vcpu *vcpu, int code, u +static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva, u8 ar, + enum gacc_mode mode, enum prot_type prot) +{ -+ return trans_exc_ending(vcpu, code, gva, ar, mode, prot, true); ++ return trans_exc_ending(vcpu, code, gva, ar, mode, prot, false); +} + static int get_vcpu_asce(struct kvm_vcpu *vcpu, union asce *asce, unsigned long ga, u8 ar, enum gacc_mode mode) { @@ arch/s390/kvm/gaccess.c: int access_guest_with_key(struct kvm_vcpu *vcpu, unsigned long ga, u8 ar, + data += fragment_len; ga = kvm_s390_logical_to_effective(vcpu, ga + fragment_len); } - if (rc > 0) +- if (rc > 0) - rc = trans_exc(vcpu, rc, ga, ar, mode, prot); -+ rc = trans_exc_ending(vcpu, rc, ga, ar, mode, prot, -+ (mode != GACC_STORE) || (idx == 0)); ++ if (rc > 0) { ++ bool terminate = (mode == GACC_STORE) && (idx > 0); ++ ++ rc = trans_exc_ending(vcpu, rc, ga, ar, mode, prot, terminate); ++ } out_unlock: if (need_ipte_lock) ipte_unlock(vcpu); 2: 434d96c63cb5 ! 2: d3a152fe6aec KVM: s390: selftest: Test suppression indication on key prot exception @@ Commit message Signed-off-by: Janis Schoetterl-Glausch <scgl(a)linux.ibm.com> ## tools/testing/selftests/kvm/s390x/memop.c ## +@@ + #include <string.h> + #include <sys/ioctl.h> + ++#include <linux/bits.h> ++ + #include "test_util.h" + #include "kvm_util.h" + @@ tools/testing/selftests/kvm/s390x/memop.c: static int err_memop_ioctl(struct test_vcpu vcpu, struct kvm_s390_mem_op *ksmo) #define SIDA_OFFSET(o) ._sida_offset = 1, .sida_offset = (o) #define AR(a) ._ar = 1, .ar = (a) @@ tools/testing/selftests/kvm/s390x/memop.c: static void test_errors_key(void) + struct test_default t = test_default_init(guest_error_key); + uint64_t prefix; + uint64_t teid; ++ uint64_t teid_mask = BIT(63 - 56) | BIT(63 - 60) | BIT(63 - 61); + uint64_t psw[2]; + + HOST_SYNC(t.vcpu, STAGE_INITED); @@ tools/testing/selftests/kvm/s390x/memop.c: static void test_errors_key(void) + HOST_SYNC(t.vcpu, STAGE_IDLED); + MOP(t.vm, ABSOLUTE, READ, &teid, sizeof(teid), GADDR(prefix + 168)); + /* Bits 56, 60, 61 form a code, 0 being the only one allowing for termination */ -+ ASSERT_EQ(teid & 0x4c, 0); ++ ASSERT_EQ(teid & teid_mask, 0); + + kvm_vm_free(t.kvm_vm); +} base-commit: c5eb0a61238dd6faf37f58c9ce61c9980aaffd7a -- 2.32.0

2 years, 7 months

2
3
0 0

[PATCH bpf v2 2/4] bpf_trace: support 32-bit kernels in bpf_kprobe_multi_link_attach

by Eugene Syromiatnikov

It seems that there is no reason not to support 32-bit architectures; doing so requires a bit of rework with respect to cookies handling, however, as the current code implicitly assumes that sizeof(long) == sizeof(u64). Signed-off-by: Eugene Syromiatnikov <esyr(a)redhat.com> --- kernel/trace/bpf_trace.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index f1d4e68..bf5bcfb 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -2406,16 +2406,12 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr struct bpf_link_primer link_primer; void __user *ucookies; unsigned long *addrs; - u32 flags, cnt, size; + u32 flags, cnt, size, cookies_size; void __user *uaddrs; u64 *cookies = NULL; void __user *usyms; int err; - /* no support for 32bit archs yet */ - if (sizeof(u64) != sizeof(void *)) - return -EOPNOTSUPP; - if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI) return -EINVAL; @@ -2425,6 +2421,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr uaddrs = u64_to_user_ptr(attr->link_create.kprobe_multi.addrs); usyms = u64_to_user_ptr(attr->link_create.kprobe_multi.syms); + ucookies = u64_to_user_ptr(attr->link_create.kprobe_multi.cookies); if (!!uaddrs == !!usyms) return -EINVAL; @@ -2432,8 +2429,11 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr if (!cnt) return -EINVAL; - if (check_mul_overflow(cnt, (u32)sizeof(*addrs), &size)) + if (check_mul_overflow(cnt, (u32)sizeof(*addrs), &size) || + (ucookies && + check_mul_overflow(cnt, (u32)sizeof(*cookies), &cookies_size))) { return -EOVERFLOW; + } size = cnt * sizeof(*addrs); addrs = kvmalloc(size, GFP_KERNEL); if (!addrs) @@ -2450,14 +2450,14 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr goto error; } - ucookies = u64_to_user_ptr(attr->link_create.kprobe_multi.cookies); if (ucookies) { - cookies = kvmalloc(size, GFP_KERNEL); + cookies_size = cnt * sizeof(*cookies); + cookies = kvmalloc(cookies_size, GFP_KERNEL); if (!cookies) { err = -ENOMEM; goto error; } - if (copy_from_user(cookies, ucookies, size)) { + if (copy_from_user(cookies, ucookies, cookies_size)) { err = -EFAULT; goto error; } -- 2.1.4

2 years, 7 months

2
1
0 0

[PATCH bpf v2 1/4] bpf_trace: check size for overflow in bpf_kprobe_multi_link_attach

by Eugene Syromiatnikov

Check that size would not overflow before calculation (and return -EOVERFLOW if it will), to prevent potential out-of-bounds write with the following copy_from_user. Add the same check to kprobe_multi_resolve_syms in case it will be called from elsewhere in the future. Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link") Signed-off-by: Eugene Syromiatnikov <esyr(a)redhat.com> --- kernel/trace/bpf_trace.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index d8553f4..f1d4e68 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -2352,12 +2352,15 @@ static int kprobe_multi_resolve_syms(const void __user *usyms, u32 cnt, unsigned long *addrs) { - unsigned long addr, size; + unsigned long addr, sym_size; + u32 size; const char __user **syms; int err = -ENOMEM; unsigned int i; char *func; + if (check_mul_overflow(cnt, (u32)sizeof(*syms), &size)) + return -EOVERFLOW; size = cnt * sizeof(*syms); syms = kvzalloc(size, GFP_KERNEL); if (!syms) @@ -2382,9 +2385,9 @@ kprobe_multi_resolve_syms(const void __user *usyms, u32 cnt, addr = kallsyms_lookup_name(func); if (!addr) goto error; - if (!kallsyms_lookup_size_offset(addr, &size, NULL)) + if (!kallsyms_lookup_size_offset(addr, &sym_size, NULL)) goto error; - addr = ftrace_location_range(addr, addr + size - 1); + addr = ftrace_location_range(addr, addr + sym_size - 1); if (!addr) goto error; addrs[i] = addr; @@ -2429,6 +2432,8 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr if (!cnt) return -EINVAL; + if (check_mul_overflow(cnt, (u32)sizeof(*addrs), &size)) + return -EOVERFLOW; size = cnt * sizeof(*addrs); addrs = kvmalloc(size, GFP_KERNEL); if (!addrs) -- 2.1.4

2 years, 7 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror May 2022