CVE-2024-27308 in mio
Summary
by MITRE • 03/06/2024
Mio is a Metal I/O library for Rust. When using named pipes on Windows, mio will under some circumstances return invalid tokens that correspond to named pipes that have already been deregistered from the mio registry. The impact of this vulnerability depends on how mio is used. For some applications, invalid tokens may be ignored or cause a warning or a crash. On the other hand, for applications that store pointers in the tokens, this vulnerability may result in a use-after-free. For users of Tokio, this vulnerability is serious and can result in a use-after-free in Tokio. The vulnerability is Windows-specific, and can only happen if you are using named pipes. Other IO resources are not affected. This vulnerability has been fixed in mio v0.8.11. All versions of mio between v0.7.2 and v0.8.10 are vulnerable. Tokio is vulnerable when you are using a vulnerable version of mio AND you are using at least Tokio v1.30.0. Versions of Tokio prior to v1.30.0 will ignore invalid tokens, so they are not vulnerable. Vulnerable libraries that use mio can work around this issue by detecting and ignoring invalid tokens.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 12/05/2025
The vulnerability identified as CVE-2024-27308 affects the mio library, a Metal I/O library for Rust that provides asynchronous I/O capabilities. This issue specifically targets Windows systems where named pipes are utilized within mio's event loop mechanisms. The flaw manifests when mio returns invalid tokens corresponding to named pipes that have already been deregistered from the library's internal registry. This represents a critical design oversight in the token management system where the library fails to properly track the lifecycle of registered I/O resources, creating a scenario where stale references persist in the system even after resources have been formally removed.
The technical implementation of this vulnerability stems from improper state management within mio's registry system. When named pipes are deregistered from the mio event loop, the underlying token references should be invalidated or removed from the system entirely. However, in certain circumstances, the library maintains references to these previously deregistered resources, leading to a condition where applications receive tokens that point to non-existent or already freed resources. This issue is particularly concerning because it directly violates fundamental memory safety principles and can lead to unpredictable behavior in applications that rely on these token values for resource management.
The operational impact of this vulnerability varies significantly based on how applications utilize the mio library. For applications that simply ignore invalid tokens or handle them gracefully, the consequences may manifest as warnings or application crashes, which while disruptive, do not necessarily result in severe security implications. However, for applications that store pointers or other critical data structures within these tokens, the vulnerability becomes far more dangerous as it can lead to use-after-free conditions. This particular scenario represents a serious security concern because use-after-free vulnerabilities are commonly exploited by attackers to achieve arbitrary code execution through memory corruption attacks, making this vulnerability particularly dangerous in security-sensitive applications.
The vulnerability is specifically Windows-dependent and only affects systems using named pipes through the mio library. This limitation reduces the overall attack surface but does not diminish the severity for affected applications. The impact extends beyond standalone mio usage to applications built on top of libraries that depend on mio, particularly Tokio. When Tokio applications use vulnerable versions of mio (specifically versions between v0.7.2 and v0.8.10) and are running Tokio v1.30.0 or later, they become vulnerable to use-after-free conditions that can be exploited by attackers. This cross-library dependency creates a cascading security risk where vulnerabilities in one component can compromise entire application stacks. The vulnerability has been addressed in mio version 0.8.11, with affected versions including all releases between v0.7.2 and v0.8.10. Applications using Tokio versions prior to v1.30.0 remain unaffected as these older versions automatically ignore invalid tokens, demonstrating how version compatibility and defensive programming practices can mitigate security risks.
The remediation approach for this vulnerability involves updating to mio version 0.8.11 or later, which implements proper token invalidation mechanisms for deregistered named pipes. Additionally, applications that cannot immediately update can implement workarounds by detecting and ignoring invalid tokens within their own codebases. This vulnerability aligns with CWE-415, which addresses double free errors, and CWE-416, which covers use after free conditions. From an ATT&CK perspective, this vulnerability could be leveraged as part of a privilege escalation or code execution attack vector, potentially mapping to techniques such as T1059 for command and script injection or T1068 for exploit for privilege escalation, depending on the specific attack scenario and target environment. The fix implemented by the mio maintainers demonstrates proper resource management practices and reinforces the importance of robust token lifecycle management in asynchronous I/O systems.