CVE-2026-64584: usb: gadget: f_midi: cancel pending IN work before freeing the midi object

From: Greg Kroah-Hartman <[email protected]>

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.

The Linux kernel CVE team has assigned CVE-2026-64584 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.12 with commit 8653d71ce3763aedcf3d2331f59beda3fecd79e4 and fixed in 6.6.148 with commit 380b4bef46c2eb260c7a9c6bb2c5be33ce5a38f9
	Issue introduced in 5.12 with commit 8653d71ce3763aedcf3d2331f59beda3fecd79e4 and fixed in 6.12.101 with commit 87bc316dd6fc90072297c635e10b9aa6075ecda1
	Issue introduced in 5.12 with commit 8653d71ce3763aedcf3d2331f59beda3fecd79e4 and fixed in 6.18.42 with commit f45089eaad0a083d71d84ff175741d7e157d9b69
	Issue introduced in 5.12 with commit 8653d71ce3763aedcf3d2331f59beda3fecd79e4 and fixed in 7.1.6 with commit ac9a51d910bb7465c554c45320cb6c09f3d0b49d
	Issue introduced in 5.12 with commit 8653d71ce3763aedcf3d2331f59beda3fecd79e4 and fixed in 7.2-rc5 with commit 5650c18d93a1db7e27cb5a40b394747eb4686d5b
	Issue introduced in 5.4.291 with commit 89019ab7a64fcdf98a2ba7799e5c6aff58d4a05d
	Issue introduced in 5.10.235 with commit 3635523e9b96213969693c320302d536774d8e9b

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64584
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/usb/gadget/function/f_midi.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/380b4bef46c2eb260c7a9c6bb2c5be33ce5a38f9
	https://git.kernel.org/stable/c/87bc316dd6fc90072297c635e10b9aa6075ecda1
	https://git.kernel.org/stable/c/f45089eaad0a083d71d84ff175741d7e157d9b69
	https://git.kernel.org/stable/c/ac9a51d910bb7465c554c45320cb6c09f3d0b49d
	https://git.kernel.org/stable/c/5650c18d93a1db7e27cb5a40b394747eb4686d5b