Hi all,
CVE-2024-56741 is supposed to be fixed by commit 7290f5923191 "apparmor:
test: Fix memory leak for aa_unpack_strdup()" but I think this
assignment should be rejected.
While a user-triggered memory leak may be exploitable for denial-of-
service, the code that was fixed here is a part of KUnit tests.
KUnit tests usually run a single time at boot, not under user control,
and can then later be invoked through debugfs by the root user.
Firstly, it is intended that the root user can deny service through the
reboot system call, so I don't think additional ways to do this are
security flaws.
Secondly, the KUnit documentation at <https://docs.kernel.org/dev-
tools/kunit/run_manual.html> says:
Note:
KUnit is not designed for use in a production system. It is possible
that tests may reduce the stability or security of the system.
so I don't think security issues in KUnit tests generally deserve CVE
IDs. (That said, the help text for CONFIG_KUNIT does not have such a
warning.)
Ben.
--
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.
The following series fixes some bugs and adding some error messages
which are not handled.
This also add some selftests which tests the new error messages.
Thank you,
---
Masami Hiramatsu (Google) (8):
tracing: tprobe-events: Fix a memory leak when tprobe with $retval
tracing: tprobe-events: Reject invalid tracepoint name
tracing: fprobe-events: Log error for exceeding the number of entry args
tracing: probe-events: Log errro for exceeding the number of arguments
tracing: probe-events: Remove unused MAX_ARG_BUF_LEN macro
selftests/ftrace: Expand the tprobe event test to check wrong format
selftests/ftrace: Add new syntax error test
selftests/ftrace: Add dynamic events argument limitation test case
kernel/trace/trace_eprobe.c | 2 +
kernel/trace/trace_fprobe.c | 25 +++++++++++-
kernel/trace/trace_kprobe.c | 5 ++
kernel/trace/trace_probe.h | 6 ++-
kernel/trace/trace_uprobe.c | 9 +++-
.../ftrace/test.d/dynevent/add_remove_tprobe.tc | 14 +++++++
.../ftrace/test.d/dynevent/dynevent_limitations.tc | 42 ++++++++++++++++++++
.../ftrace/test.d/dynevent/fprobe_syntax_errors.tc | 1
8 files changed, 98 insertions(+), 6 deletions(-)
create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/dynevent_limitations.tc
--
Masami Hiramatsu (Google) <mhiramat(a)kernel.org>
The nolibc testsuite can be run against other libcs to test for
interoperability. Some aspects of the constructor execution are not
standardized and musl does not provide all tested feature, for one it
does not provide arguments to the constructors, anymore?
Skip the constructor tests on non-nolibc configurations.
Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net>
---
tools/testing/selftests/nolibc/nolibc-test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index 798fbdcd3ff8c36b514feb3fa1c7b8d7701cccd7..94db506eca906ff0ce8f518298dee34abf386484 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -738,9 +738,9 @@ int run_startup(int min, int max)
CASE_TEST(environ_HOME); EXPECT_PTRNZ(1, getenv("HOME")); break;
CASE_TEST(auxv_addr); EXPECT_PTRGT(test_auxv != (void *)-1, test_auxv, brk); break;
CASE_TEST(auxv_AT_UID); EXPECT_EQ(1, getauxval(AT_UID), getuid()); break;
- CASE_TEST(constructor); EXPECT_EQ(1, constructor_test_value, 2); break;
+ CASE_TEST(constructor); EXPECT_EQ(is_nolibc, constructor_test_value, 2); break;
CASE_TEST(linkage_errno); EXPECT_PTREQ(1, linkage_test_errno_addr(), &errno); break;
- CASE_TEST(linkage_constr); EXPECT_EQ(1, linkage_test_constructor_test_value, 6); break;
+ CASE_TEST(linkage_constr); EXPECT_EQ(is_nolibc, linkage_test_constructor_test_value, 6); break;
case __LINE__:
return ret; /* must be last */
/* note: do not set any defaults so as to permit holes above */
---
base-commit: 16681bea9a80080765c98b545ad74c17de2d513c
change-id: 20250212-nolibc-test-constructor-42491ba71a19
Best regards,
--
Thomas Weißschuh <linux(a)weissschuh.net>
While nolibc does support ARM Thumb instructions,
that support was not tested specifically.
Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net>
---
Thomas Weißschuh (2):
selftests/nolibc: explicitly enable ARM mode
selftests/nolibc: add armthumb configuration
tools/testing/selftests/nolibc/Makefile | 7 +++++++
tools/testing/selftests/nolibc/run-tests.sh | 5 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
---
base-commit: 3bd53b2fa57d9472d3af63b3f4d26023ba07b579
change-id: 20250228-nolibc-armthumb-372963140267
Best regards,
--
Thomas Weißschuh <linux(a)weissschuh.net>