-
CVSS Score
-Basic Information
Technical Details
Vulnerability Intelligence
Miggo AI
Miggo AIMiggo AI| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| process-sync | rust | <= 0.2.2 |
Miggo AIRoot Cause AnalysisThe vulnerability, CVE-2025-48752, lies in the process-sync Rust crate, specifically within the SharedMutex::drop method. The core issue, as detailed in GitHub issue #3 for the Forestryks/process-sync-rs repository, is that the drop implementation does not ensure the pthread_mutex_t is unlocked before calling pthread_mutex_destroy.
The NVD description and the GitHub issue both confirm that this lack of a check is the vulnerability. The issue explicitly points to the vulnerable code in src/mutex.rs (lines 123-128 in commit f1a207a, which corresponds to version 0.2.2, the latest vulnerable version). The code snippet shows pthread_mutex_destroy being called unconditionally (if the process ID matches the owner PID), without any prior check on the lock state of the mutex.
If a SharedMutex object is dropped while the mutex is held (e.g., after a call to lock() and before unlock()), pthread_mutex_destroy will be invoked on a locked mutex. This action is explicitly defined as leading to undefined behavior by POSIX standards, potentially causing crashes, deadlocks, or other unpredictable program states. The vulnerability is exploitable in scenarios where a SharedMutex can be dropped while in a locked state. The provided PoC in the issue (if let Ok(mut s) = SharedMutex::new(){ if let Ok(_) = s.lock(){ drop(s); } }) clearly illustrates how this can occur.
Therefore, the function process_sync::mutex::SharedMutex::drop is the direct site of the vulnerability. During exploitation or when the bug is triggered, this function would be on the call stack as it executes the unsafe pthread_mutex_destroy call on a potentially locked mutex.