Description

The user-space system-call verifier z_vrfy_z_log_msg_static_create() in subsys/logging/log_msg.c was a pure pass-through: it forwarded the caller-supplied source, desc, package, and data arguments directly to the kernel-mode implementation z_impl_z_log_msg_static_create() without performing any of the mandatory K_SYSCALL_* checks. Because z_log_msg_static_create() is declared __syscall, under CONFIG_USERSPACE any unprivileged user-mode thread can invoke it directly with fully attacker-controlled arguments. The kernel-mode handler dereferences each of these untrusted values: frontend_runtime_filtering() reads through the source pointer as a struct log_source_dynamic_data, cbprintf_package_copy() reads desc.package_len bytes from the package pointer, and z_log_msg_finalize() performs a memcpy() of desc.data_len bytes from the data pointer. With no verification, a user thread can supply arbitrary kernel addresses and arbitrary lengths, and the kernel will read from them. The impact is a kernel-mode denial of service (the kernel faults dereferencing an attacker-chosen pointer) and, where a log backend output is observable to the attacker, disclosure of arbitrary kernel memory copied into the emitted log message — a confidentiality breach across the user/kernel boundary that the userspace sandbox is meant to enforce. The reads do not corrupt kernel memory, so there is no out-of-bounds write primitive. The fix adds the required validation to the verifier: it bounds desc.package_len against Z_LOG_MSG_MAX_PACKAGE, rejects non-NULL/length mismatches, and applies K_SYSCALL_MEMORY_READ() to package, data, and (when runtime filtering with a frontend is enabled) source, so any out-of-bounds or kernel pointer now raises K_OOPS instead of being honored.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-08-14T18:17:21.820Z",
  "pubdate": "2026-08-14T18:17:21.820Z",
  "executiveSummary": "A vulnerability exists in the user-space system-call verifier z_vrfy_z_log_msg_static_create() within subsys/logging/log_msg.c under CONFIG_USERSPACE configurations.\nThe vulnerability type is a missing privilege and bounds check, leading to unauthorized arbitrary kernel memory read access.\nThe impact includes kernel-mode denial of service via kernel faults and a confidentiality breach allowing the disclosure of arbitrary kernel memory copied into emitted log messages.\nAffected systems are those running the Zephyr RTOS with CONFIG_USERSPACE enabled where the logging subsystem processes untrusted system calls.\nRisk implications center on the breakdown of the user/kernel boundary enforcement expected from the userspace sandbox.\nAttacker capabilities require unprivileged user-mode thread execution to invoke the system call directly with fully attacker-controlled arguments.\nExploitation requirements involve an attacker supplying arbitrary kernel addresses and arbitrary lengths to trigger unauthorized reads and observe the output via an observable log backend.",
  "technicalDetails": "The vulnerable component is the user-space system-call verifier z_vrfy_z_log_msg_static_create() located in subsys/logging/log_msg.c.\nThe root cause of the vulnerability is that the verifier functions as a pure pass-through, forwarding the caller-supplied source, desc, package, and data arguments directly to the kernel-mode implementation z_impl_z_log_msg_static_create() without performing any mandatory K_SYSCALL_* validation checks.\nBecause z_log_msg_static_create() is declared with the __syscall attribute, any unprivileged user-mode thread can invoke it directly under CONFIG_USERSPACE with fully attacker-controlled inputs.\nThe attack flow proceeds as follows: First, an unprivileged user-mode thread crafts a malicious system call invocation to z_log_msg_static_create() providing arbitrary memory addresses and lengths for the source, package, and data arguments.\nSecond, the kernel-mode handler directly dereferences these untrusted values without validation.\nThird, frontend_runtime_filtering() reads through the attacker-supplied source pointer as a struct log_source_dynamic_data.\nFourth, cbprintf_package_copy() reads desc.package_len bytes from the attacker-controlled package pointer.\nFifth, z_log_msg_finalize() performs a memcpy() of desc.data_len bytes from the attacker-controlled data pointer.\nSixth, the kernel reads from these arbitrary kernel addresses, resulting in kernel-mode denial of service if an invalid pointer causes a kernel fault, or confidentiality breach if the memory is copied into a log message and observed via a log backend output.\nPrivilege requirements are minimal, needing only an unprivileged user-mode thread within the sandbox.\nAuthentication requirements are absent beyond standard user-mode execution capabilities.\nThe reads do not corrupt kernel memory, meaning there is no out-of-bounds write primitive associated with this specific payload behavior."
}