CVE-2026-9728: TOCTOU race in mbox_send syscall verifier allows userspace to leak kernel memory
The userspace syscall verifier zvrfymboxsend() in drivers/mbox/mboxhandlers.c validated the nested msg->data/msg->size fields by reading them directly out of live userspace memory, and then forwarded the original, still-mutable userspace struct mboxmsg pointer to zimplmboxsend() and the underlying driver. Between the access check and the driver's use of msg->data, the validated pointer could be replaced, leaving a time-of-check/time-of-use window.
On a system built with CONFIGUSERSPACE, any unprivileged userspace thread may invoke the mboxsend() system call. A second thread sharing the caller's address space can race to overwrite msg->data with a supervisor (kernel) address after the verifier's bounds check has passed but before the driver dereferences it. The driver then reads from the attacker-chosen address in supervisor context (for example memcpy(&data32, msg->data, msg->size) in the NXP mailbox driver, whose bytes are subsequently emitted to the peer mailbox endpoint).
The impact is a userspace-to-supervisor access-control bypass: disclosure of kernel memory contents (high confidentiality impact), or, for an invalid/unmapped target address, a faulting kernel read causing denial of service. The fix snapshots the entire struct mboxmsg into a kernel-stack copy with kusermodefromcopy() and validates and forwards that immutable copy, closing the race.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
On systems built with CONFIG_USERSPACE, mitigate the TOCTOU issue in the mbox_send() syscall verifier by applying the fix that snapshots the entire mbox_msg struct into a kernel-stack copy via k_usermode_from_copy(), validates that immutable copy, and forwards only the copied data to the underlying implementation/driver.
Linux kernel userspace configuration CONFIG_USERSPACE = enabled/available (per statement)
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems built with CONFIG_USERSPACE are exposed because unprivileged userspace threads can invoke mbox_send(). Exploitation also depends on a mailbox driver dereferencing the mutable message data pointer in supervisor context.
What does an attacker need to exploit the race?
An unprivileged userspace thread must call mbox_send() with a message structure in userspace memory, while a second thread sharing the same address space races to replace msg->data after validation. The replacement pointer targets a supervisor address that the mailbox driver subsequently reads.
What is the likely impact of a successful exploit?
A successful race can cause a mailbox driver to read attacker-selected kernel memory and emit those bytes to a peer mailbox endpoint, disclosing kernel contents. Supplying an invalid or unmapped target address can instead cause a faulting kernel read.