Description

NetBSD contains a use-after-free and double-free vulnerability in msg_recv_copyin() within the COMPAT_NETBSD32 compatibility layer due to a missing return statement before the cleanup label on the success path. Any local user able to execute a 32-bit binary on a 64-bit NetBSD system can trigger a kernel panic or memory corruption by calling recvmsg() with msg_iovlen between 9 and IOV_MAX, causing the kernel to access a freed iovec buffer and subsequently free the same allocation a second time.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.0",
  "pubDate": "2026-09-11T14:17:27.873Z",
  "pubdate": "2026-09-11T14:17:27.873Z",
  "executiveSummary": "This vulnerability involves a critical use-after-free and double-free flaw within the NetBSD kernel's COMPAT_NETBSD32 compatibility layer. Specifically located in the msg_recv_copyin() function, the issue stems from an erroneous control flow path where a missing return statement permits execution to proceed into a cleanup label despite a successful operation.\nThe vulnerability affects 64-bit NetBSD systems running 32-bit binaries. It allows a local, unprivileged attacker to trigger kernel memory corruption or a system panic. By invoking the recvmsg() system call with a specifically crafted msg_iovlen parameter ranging between 9 and IOV_MAX, the attacker forces the kernel to interact with a buffer that has already been deallocated.\nThis flaw represents a significant security risk, as memory corruption vulnerabilities in the kernel address space can potentially lead to arbitrary code execution or full system compromise. The primary requirement for exploitation is the ability for a local user to execute 32-bit code on the target 64-bit architecture. Immediate patching or disabling the affected compatibility layer is advised to mitigate potential exploitation.",
  "technicalDetails": "The root cause of this vulnerability is an implementation error within the msg_recv_copyin() function, which is responsible for handling 32-bit socket message structures in the NetBSD kernel. During the processing of the iovec buffer—which translates 32-bit iovec structures to their 64-bit equivalents—a logic branch responsible for success handling fails to terminate execution before falling through to the cleanup label.\nWhen a user process invokes recvmsg() with an msg_iovlen value between 9 and IOV_MAX, the kernel allocates memory to manage these I/O vectors. Under the vulnerable code path, the function performs the copy-in operation successfully but lacks the required return statement after the success path. Consequently, the execution flow continues into the error/cleanup path, which invokes free() on the allocated iovec buffer.\nThe attack flow follows these steps: 1) The attacker executes a 32-bit binary that calls recvmsg() with the targeted msg_iovlen range. 2) The msg_recv_copyin() function processes the request and allocates a kernel-space buffer for the iovec data. 3) Due to the missing return, the kernel reaches the cleanup label and frees the newly allocated buffer while the kernel still maintains a reference to it in the ongoing system call execution. 4) The kernel continues to utilize the pointer to the freed memory, resulting in a use-after-free condition. 5) Finally, the routine may attempt to free the same memory address again upon exiting the function or via secondary cleanup mechanisms, leading to a double-free condition. This double-free is particularly dangerous as it can corrupt the kernel memory allocator's metadata, potentially enabling an attacker to gain control over kernel memory structures.\nThis vulnerability does not require network exposure or remote authentication; it is constrained to the local environment. However, the requirement for local access is easily met in multi-user environments or systems allowing untrusted code execution. The impact of successful exploitation ranges from a localized kernel panic (denial of service) to full system compromise if the memory corruption is leveraged to overwrite critical kernel data structures, function pointers, or credential objects within the kernel address space."
}