CVE-2026-64584
usb: gadget: f_midi: cancel pending IN work before freeing the midi object
Description
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.
INFO
Published Date :
Aug. 6, 2026, 8:16 a.m.
Last Modified :
Aug. 6, 2026, 8:16 a.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products
The following products are affected by CVE-2026-64584
vulnerability.
Even if cvefeed.io is aware of the exact versions of the
products
that
are
affected, the information is not represented in the table below.
No affected product recoded yet
Solution
- Cancel pending work items before freeing the object.
- Synchronize work item execution during object free.
- Ensure all references are dropped before freeing.
- Apply the provided kernel patch.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-64584.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-64584 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-64584
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-64584 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-64584 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 06, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '8653d71ce3763aedcf3d2331f59beda3fecd79e4', 'lessThan': '380b4bef46c2eb260c7a9c6bb2c5be33ce5a38f9', 'versionType': 'git'}, {'status': 'affected', 'version': '8653d71ce3763aedcf3d2331f59beda3fecd79e4', 'lessThan': '87bc316dd6fc90072297c635e10b9aa6075ecda1', 'versionType': 'git'}, {'status': 'affected', 'version': '8653d71ce3763aedcf3d2331f59beda3fecd79e4', 'lessThan': 'f45089eaad0a083d71d84ff175741d7e157d9b69', 'versionType': 'git'}, {'status': 'affected', 'version': '8653d71ce3763aedcf3d2331f59beda3fecd79e4', 'lessThan': 'ac9a51d910bb7465c554c45320cb6c09f3d0b49d', 'versionType': 'git'}, {'status': 'affected', 'version': '8653d71ce3763aedcf3d2331f59beda3fecd79e4', 'lessThan': '5650c18d93a1db7e27cb5a40b394747eb4686d5b', 'versionType': 'git'}, {'status': 'affected', 'version': '89019ab7a64fcdf98a2ba7799e5c6aff58d4a05d', 'versionType': 'git'}, {'status': 'affected', 'version': '3635523e9b96213969693c320302d536774d8e9b', 'versionType': 'git'}, {'status': 'affected', 'version': '5.4.291', 'lessThan': '5.5', 'versionType': 'semver'}, {'status': 'affected', 'version': '5.10.235', 'lessThan': '5.11', 'versionType': 'semver'}], 'programFiles': ['drivers/usb/gadget/function/f_midi.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '5.12'}, {'status': 'unaffected', 'version': '0', 'lessThan': '5.12', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '6.6.148', 'versionType': 'semver', 'lessThanOrEqual': '6.6.*'}, {'status': 'unaffected', 'version': '6.12.101', 'versionType': 'semver', 'lessThanOrEqual': '6.12.*'}, {'status': 'unaffected', 'version': '6.18.42', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '7.1.6', 'versionType': 'semver', 'lessThanOrEqual': '7.1.*'}, {'status': 'unaffected', 'version': '7.2-rc5', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['drivers/usb/gadget/function/f_midi.c'], 'defaultStatus': 'affected'}] Added Description In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool. Added Reference https://git.kernel.org/stable/c/380b4bef46c2eb260c7a9c6bb2c5be33ce5a38f9 Added Reference https://git.kernel.org/stable/c/5650c18d93a1db7e27cb5a40b394747eb4686d5b Added Reference https://git.kernel.org/stable/c/87bc316dd6fc90072297c635e10b9aa6075ecda1 Added Reference https://git.kernel.org/stable/c/ac9a51d910bb7465c554c45320cb6c09f3d0b49d Added Reference https://git.kernel.org/stable/c/f45089eaad0a083d71d84ff175741d7e157d9b69