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>
The upcoming new Idle HLT Intercept feature allows for the HLT
instruction execution by a vCPU to be intercepted by the hypervisor
only if there are no pending V_INTR and V_NMI events for the vCPU.
When the vCPU is expected to service the pending V_INTR and V_NMI
events, the Idle HLT intercept won’t trigger. The feature allows the
hypervisor to determine if the vCPU is actually idle and reduces
wasteful VMEXITs.
The Idle HLT intercept feature is used for enlightened guests who wish
to securely handle the events. When an enlightened guest does a HLT
while an interrupt is pending, hypervisor will not have a way to
figure out whether the guest needs to be re-entered or not. The Idle
HLT intercept feature allows the HLT execution only if there are no
pending V_INTR and V_NMI events.
Presence of the Idle HLT Intercept feature is indicated via CPUID
function Fn8000_000A_EDX[30].
Document for the Idle HLT intercept feature is available at [1].
This series is based on kvm-x86/next (eb723766b103) + [2].
Testing Done:
- Tested the functionality for the Idle HLT intercept feature
using selftest ipi_hlt_test.
- Tested on normal, SEV, SEV-ES, SEV-SNP guest for the Idle HLT intercept
functionality.
- Tested the Idle HLT intercept functionality on nested guest.
v5 -> v6
- Incorporated Neeraj's review comments on selftest.
v4 -> v5
- Incorporated Sean's review comments on nested Idle HLT intercept support.
- Make svm_idle_hlt_test independent of the Idle HLT to run on all hardware.
v3 -> v4
- Drop the patches to add vcpu_get_stat() into a new series [2].
- Added nested Idle HLT intercept support.
v2 -> v3
- Incorporated Andrew's suggestion to structure vcpu_stat_types in
a way that each architecture can share the generic types and also
provide its own.
v1 -> v2
- Did changes in svm_idle_hlt_test based on the review comments from Sean.
- Added an enum based approach to get binary stats in vcpu_get_stat() which
doesn't use string to get stat data based on the comments from Sean.
- Added safe_halt() and cli() helpers based on the comments from Sean.
[1]: AMD64 Architecture Programmer's Manual Pub. 24593, April 2024,
Vol 2, 15.9 Instruction Intercepts (Table 15-7: IDLE_HLT).
https://bugzilla.kernel.org/attachment.cgi?id=306251
[2]: https://lore.kernel.org/kvm/ee027335-f1b9-4637-bc79-27a610c1ab08@amd.com/T/…
---
V5: https://lore.kernel.org/kvm/20250103081828.7060-1-manali.shukla@amd.com/
V4: https://lore.kernel.org/kvm/20241022054810.23369-1-manali.shukla@amd.com/
V3: https://lore.kernel.org/kvm/20240528041926.3989-4-manali.shukla@amd.com/T/
V2: https://lore.kernel.org/kvm/20240501145433.4070-1-manali.shukla@amd.com/
V1: https://lore.kernel.org/kvm/20240307054623.13632-1-manali.shukla@amd.com/
Manali Shukla (3):
x86/cpufeatures: Add CPUID feature bit for Idle HLT intercept
KVM: SVM: Add Idle HLT intercept support
KVM: selftests: Add self IPI HLT test
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/svm.h | 1 +
arch/x86/include/uapi/asm/svm.h | 2 +
arch/x86/kvm/svm/svm.c | 13 ++-
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../selftests/kvm/include/x86/processor.h | 1 +
tools/testing/selftests/kvm/ipi_hlt_test.c | 81 +++++++++++++++++++
7 files changed, 97 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/kvm/ipi_hlt_test.c
base-commit: eb723766b1030a23c38adf2348b7c3d1409d11f0
prerequisite-patch-id: cb345fc0d814a351df2b5788b76eee0eef9de549
prerequisite-patch-id: 71806f400cffe09f47d6231cb072cbdbd540de1b
prerequisite-patch-id: 9ea0412aab7ecd8555fcee3e9609dbfe8456d47b
prerequisite-patch-id: 3504df50cdd33958456f2e56139d76867273525c
prerequisite-patch-id: 674e56729a56cc487cb85be1a64ef561eb7bac8a
prerequisite-patch-id: 48e87354f9d6e6bd121ca32ab73cd0d7f1dce74f
prerequisite-patch-id: b32c21df6522a7396baa41d62bcad9479041d97a
prerequisite-patch-id: 0ff4b504e982db7c1dfa8ec6ac485c92a89f4af8
prerequisite-patch-id: 509018dc2fc1657debc641544e86f5a92d04bc1a
--
2.34.1