https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 16:40:11 +0000 https://vulnerability.circl.lu/vuln/cve-2026-64343 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>USB: ldusb: fix use-after-free on disconnect race</p> <p>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]</p> <p>Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect().</p> <p>[1] a51749ab34d9 (&#34;locking/mutex: Document that mutex_unlock() is non-atomic&#34;) [2] 2b9d9e0a9ba0 (&#34;locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it&#39;s unlocked&#34;)</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>USB: ldusb: fix use-after-free on disconnect race</p> <p>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]</p> <p>Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect().</p> <p>[1] a51749ab34d9 (&#34;locking/mutex: Document that mutex_unlock() is non-atomic&#34;) [2] 2b9d9e0a9ba0 (&#34;locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it&#39;s unlocked&#34;)</p> https://vulnerability.circl.lu/vuln/cve-2026-64343