CVE-2026-64584

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_midi: cancel pending IN work before freeing the midi object<br /> <br /> The f_midi driver embeds a work item (midi-&gt;work) whose handler,<br /> f_midi_in_work(), dereferences the enclosing struct f_midi through<br /> container_of(). This work is armed from two sites: f_midi_complete(),<br /> on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA<br /> rawmidi output-stream start.<br /> <br /> Neither f_midi_disable() nor f_midi_unbind() cancels midi-&gt;work.<br /> f_midi_disable() only disables the endpoints and drains the in_req_fifo;<br /> it does not synchronize the work item, and the sound card is released<br /> asynchronously to the final free of the midi object.<br /> <br /> The midi object is reference-counted (midi-&gt;free_ref) and is freed in<br /> f_midi_free() only once both the usb_function reference and the rawmidi<br /> private_data reference have been dropped. In f_midi_unbind(),<br /> f_midi_disable() runs before the sound card is released, so while the<br /> USB endpoints are already disabled the rawmidi device is still usable by<br /> an open substream. A concurrent userspace write on such a substream can<br /> reach f_midi_in_trigger() and queue midi-&gt;work again after<br /> f_midi_disable() has returned. A work item armed this way may still be<br /> pending when the last reference drops and f_midi_free() proceeds to<br /> kfree(midi), letting f_midi_in_work() dereference the struct after it<br /> has been freed, a use-after-free.<br /> <br /> For this reason cancelling midi-&gt;work in f_midi_disable() would not be<br /> sufficient: the ALSA trigger path can rearm the work after disable()<br /> returns. Cancelling at the refcount-zero free site is the boundary<br /> after which neither arming source can survive, because by then both<br /> references that keep the midi object alive have been dropped: the USB<br /> endpoints are already disabled and the rawmidi device has been released.<br /> <br /> Fix this by calling cancel_work_sync(&amp;midi-&gt;work) in the refcount-zero<br /> block of f_midi_free(), before the embedded work_struct is freed along<br /> with the rest of the structure. opts-&gt;lock is a sleeping mutex, so<br /> calling cancel_work_sync() under it is permitted, and the handler takes<br /> midi-&gt;transmit_lock rather than opts-&gt;lock, so no self-deadlock can<br /> occur while it waits for a running instance of the work to finish.<br /> <br /> This issue was found by an in-house static analysis tool.