CVE-2026-12234
NVD analysis in progress
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.
What this means
- Exposure
- Exploitable with local access to the machine, with an ordinary user account and with no action from the victim. The attack does require particular conditions, which makes it less systematic.
- Impact
- An attacker can read sensitive data, modify or destroy data and take the service offline. The impact spreads beyond the vulnerable component into other parts of the system.
- Weakness
- The checked state changes before it is used, letting the attacker swap the target in between.
- Likelihood
- Its EPSS score stays low: nothing points to imminent exploitation, which is no reason to leave it unpatched.
What to doFold into the next patch cycle.
Read automatically from the CVSS vector, the weakness type (CWE) and the EPSS score. The technical description above remains the one published by NIST.