Description

The userspace syscall verifiers z_vrfy_zsock_sendmsg() and z_vrfy_zsock_recvmsg() in subsys/net/lib/sockets/sockets.c snapshot the caller-supplied struct net_msghdr into a kernel-side copy with k_usermode_from_copy(), but then re-read the still-live user struct for subsequent decisions. The kernel iovec shadow buffer is sized from one read of msg->msg_iovlen, while the population loop is bounded by a second, live read of the same field. Because msg points into ordinary user memory, a cooperating second thread in the same memory domain can inflate msg->msg_iovlen in the window between the sizing read and the loop test (a classic double-fetch / TOCTOU). The population loop then iterates past the number of net_iovec slots actually allocated, writing attacker-influenced iov_base/iov_len values beyond the end of the kernel-heap shadow buffer. The recvmsg verifier has the same defect on both its inbound and result write-back loops. The code is reachable from an unprivileged user thread whenever CONFIG_USERSPACE is enabled and the zsock_sendmsg/zsock_recvmsg syscalls are available. A successful race corrupts kernel-managed heap memory across the user-to-kernel privilege boundary, yielding a local privilege-escalation primitive or, at minimum, a kernel-fault denial of service. The fix copies the header once and derives every size, bound, and gate from the snapshot, copying each iovec entry atomically so its base and length can no longer be raced apart.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-12T05:17:42.143Z",
  "pubdate": "2026-08-12T05:17:42.143Z",
  "executiveSummary": "A time-of-check to time-of-use (TOCTOU) double-fetch vulnerability exists in the userspace system call verifiers z_vrfy_zsock_sendmsg() and z_vrfy_zsock_recvmsg() located within subsys/net/lib/sockets/sockets.c. The vulnerability arises because the kernel snapshots a caller-supplied struct net_msghdr into a kernel-side copy using k_usermode_from_copy(), but subsequently performs re-reads of the still-live user-space structure for critical operational decisions. Specifically, the iovec shadow buffer is sized based on an initial read of msg->msg_iovlen, while the subsequent population loop is bounded by a second live read of the same field.\nA cooperating second thread within the same memory domain can exploit this window by inflating msg->msg_iovlen between the sizing allocation and the population loop. This out-of-bounds write primitive allows an attacker to corrupt kernel-managed heap memory across the user-to-kernel privilege boundary. Successful exploitation yields a local privilege-escalation primitive or a kernel-fault denial of service. The issue affects environments where CONFIG_USERSPACE is enabled and the zsock_sendmsg or zsock_recvmsg system calls are accessible to unprivileged user threads.",
  "technicalDetails": "The vulnerability is rooted in a classic double-fetch and race condition pattern affecting the userspace system call validation handlers z_vrfy_zsock_sendmsg() and z_vrfy_zsock_recvmsg() in subsys/net/lib/sockets/sockets.c. When handling user-supplied network messages, the kernel attempts to safely copy the user-space struct net_msghdr structure using k_usermode_from_copy(). However, instead of strictly utilizing the copied snapshot for all subsequent logic, the validation routines perform secondary reads directly from the user-controlled memory space.\nThe attack flow proceeds as follows: First, the kernel reads msg->msg_iovlen from user space to calculate the required allocation size for the kernel iovec shadow buffer. Second, before the population loop begins, a cooperating thread in the same user memory domain modifies the value of msg->msg_iovlen to a larger number. Third, because the population loop relies on a second live read of msg->msg_iovlen rather than the validated snapshot, the loop iterates past the bounds of the allocated kernel-heap shadow buffer. Consequently, attacker-influenced iov_base and iov_len values are written beyond the termination boundary of the kernel buffer. The recvmsg verifier suffers from an identical defect across both its inbound and result write-back loops.\nThe vulnerable component comprises the networking subsystem socket system call verifiers. Exploitation requires the attacker to execute code within an unprivileged user thread where CONFIG_USERSPACE is active and zsock_sendmsg or zsock_recvmsg system calls are exposed. No network exposure is strictly required as the attack vector originates from local user-space concurrency. The payload behavior involves heap corruption of kernel-managed memory structures, leading directly to memory integrity violations, local privilege escalation, or system instability resulting in a kernel-fault denial of service."
}