Skip to main content
CVE-2026-64344VulnerabilityPublished 07/25/2026

In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access… (CVE-2026-64344)

Source GCVE Database

0
Severity
Medium

No CVSS score published yet

Exploitation

Not in CISA KEV, no exploitation reported

EPSS
0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

What to do

AI-suggested

A fix has been implemented in the Linux kernel source to address this issue by using kref for driver data release instead of relying on mutex_unlock() for object lifetime management. Users should update to the fixed kernel versions once available.

Description

In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked")

Impact

The vulnerability could cause use-after-free conditions in the kernel USB idmouse driver, potentially leading to kernel crashes or undefined behavior. No known exploits in the wild have been reported. The impact is limited to the affected driver and kernel context where the race condition occurs.

Summary

The vulnerability in the Linux kernel USB idmouse driver is due to improper handling of object lifetime in the context of mutex_unlock(). Unlike spinlocks and refcounts, mutex_unlock() can access the mutex object after unlocking, making it unsafe to manage object lifetime directly with it. This led to a use-after-free condition when the release() function races with disconnect(). The patch replaced direct lifetime management via mutex_unlock() with a kref-based mechanism to safely release driver data, eliminating the race condition and use-after-free.

References

Community reviews

Loading reviews…