In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
usb: gadget: f_midi: cancel pending IN work before freeing the midi object<\/p>\n
The f_midi driver embeds a work item (midi->work) whose handler,
\nf_midi_in_work(), dereferences the enclosing struct f_midi through
\ncontainer_of(). This work is armed from two sites: f_midi_complete(),
\non a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA
\nrawmidi output-stream start.<\/p>\n
Neither f_midi_disable() nor f_midi_unbind() cancels midi->work.
\nf_midi_disable() only disables the endpoints and drains the in_req_fifo;
\nit does not synchronize the work item, and the sound card is released
\nasynchronously to the final free of the midi object.<\/p>\n
The midi object is reference-counted (midi->free_ref) and is freed in
\nf_midi_free() only once both the usb_function reference and the rawmidi
\nprivate_data reference have been dropped. In f_midi_unbind(),
\nf_midi_disable() runs before the sound card is released, so while the
\nUSB endpoints are already disabled the rawmidi device is still usable by
\nan open substream. A concurrent userspace write on such a substream can
\nreach f_midi_in_trigger() and queue midi->work again after
\nf_midi_disable() has returned. A work item armed this way may still be
\npending when the last reference drops and f_midi_free() proceeds to
\nkfree(midi), letting f_midi_in_work() dereference the struct after it
\nhas been freed, a use-after-free.<\/p>\n
For this reason cancelling midi->work in f_midi_disable() would not be
\nsufficient: the ALSA trigger path can rearm the work after disable()
\nreturns. Cancelling at the refcount-zero free site is the boundary
\nafter which neither arming source can survive, because by then both
\nreferences that keep the midi object alive have been dropped: the USB
\nendpoints are already disabled and the rawmidi device has been released.<\/p>\n
Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero
\nblock of f_midi_free(), before the embedded work_struct is freed along
\nwith the rest of the structure. opts->lock is a sleeping mutex, so
\ncalling cancel_work_sync() under it is permitted, and the handler takes
\nmidi->transmit_lock rather than opts->lock, so no self-deadlock can
\noccur while it waits for a running instance of the work to finish.<\/p>\n
This issue was found by an in-house static analysis tool.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
usb: gadget: f_midi: cancel pending IN work before freeing the midi object<\/p>\n
The f_midi driver embeds a work item (midi->work) whose<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-4874","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/4874","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4874"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4874"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}