CVE-2026-15449 in illumos
Summary
by MITRE • 07/16/2026
A time-of-check to time-of-use (TOCTOU) flaw in the illumos data-link pseudo-driver (dld) affects handling of the DLDIOC_GETMACPROP and DLDIOC_SETMACPROP ioctls on /dev/dld. drv_ioc_prop_common() in usr/src/uts/common/io/dld/dld_drv.c copies the dld_ioc_macprop_t ioctl header in once to read its pr_valsize field, sizes and allocates a kernel heap buffer from that value, and then copies the full request in a second time from the same unprivileged user address. A concurrent thread can enlarge pr_valsize between the two copyins, so the second copyin and the subsequent property handling write beyond the end of the undersized allocation and corrupt the kernel heap. An unprivileged local user, including one confined to a non-global zone that owns a datalink, can trigger this to panic the system. The resulting kernel heap corruption may be usable for further compromise.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/16/2026
The vulnerability described represents a critical time-of-check to time-of-use flaw in the illumos data-link pseudo-driver implementation that exposes a fundamental race condition in kernel memory management. This weakness occurs within the drv_ioc_prop_common() function located in usr/src/uts/common/io/dld/dld_drv.c, where the driver processes DLDIOC_GETMACPROP and DLDIOC_SETMACPROP ioctls through the /dev/dld device interface. The flaw stems from a design pattern where the kernel first reads the ioctl header to determine buffer sizing based on the pr_valsize field, allocates memory accordingly, and then performs a second copyin operation from the same user-supplied address. This sequential approach creates an exploitable window where concurrent threads can modify the pr_valsize field between the initial size determination and the actual data copy operations.
The technical execution of this vulnerability relies on the inherent race condition between the two memory operations that occur within the same function context. When the kernel first copies the ioctl header, it reads the pr_valsize field to determine how much memory to allocate for processing the request. However, a malicious concurrent thread can modify this value before the second copyin operation occurs, causing the kernel to allocate insufficient memory for the actual payload data. The subsequent copyin operation then writes beyond the allocated buffer boundaries, resulting in direct kernel heap corruption that can be leveraged by an unprivileged local attacker.
The operational impact of this vulnerability extends beyond simple system instability into potential privilege escalation and system compromise scenarios. An unprivileged user, including those confined to non-global zones, can trigger this vulnerability through legitimate ioctl operations on datalinks they own, making the attack surface particularly concerning for containerized environments and multi-tenant systems. The kernel heap corruption resulting from this flaw may provide attackers with opportunities for further exploitation, potentially enabling arbitrary code execution or privilege escalation within the kernel context. This weakness is particularly dangerous because it can be exploited by users with minimal privileges who have access to network datalinks, making it a significant concern for system administrators managing shared environments.
Mitigation strategies for this vulnerability should focus on eliminating the race condition through immediate code refactoring and implementing proper synchronization mechanisms around the ioctl processing operations. The recommended approach involves consolidating the two copyin operations into a single atomic operation that reads the complete header and data in one step, preventing concurrent modification of the pr_valsize field during processing. Additionally, input validation should be strengthened to ensure that buffer sizes remain consistent throughout the processing cycle, with bounds checking implemented before any memory allocation occurs. System administrators should also consider implementing zone-level restrictions on datalink access when possible, though this may not fully mitigate the vulnerability since it can be exploited even within confined zones where users possess legitimate ownership of datalinks.
This vulnerability aligns with CWE-367 Time-of-Check to Time-of-Use (TOCTOU) which specifically addresses race conditions that occur when a system's state changes between verification and actual use of resources. The flaw also relates to ATT&CK technique T1068, which covers local privilege escalation through kernel vulnerabilities, and demonstrates how seemingly minor implementation details in kernel drivers can create significant security risks. The exploitation potential of this vulnerability makes it particularly concerning for compliance frameworks such as CIS Controls and NIST SP 800-53, where maintaining system integrity and preventing unauthorized privilege escalation are critical requirements. Organizations should prioritize patching this vulnerability through official illumos updates or implementing temporary mitigations while awaiting official fixes to prevent potential exploitation in production environments.