f_midi, but its real exposure is far narrower than the CVSS 7.8 rating suggests: the affected system must be configured to act as a USB MIDI device, not merely use a USB MIDI controller or keyboard.The vulnerability was published to the CVE List on August 6 and is documented by NIST’s National Vulnerability Database from the Linux kernel project’s advisory. Linux 7.2-rc5, released on July 26, already includes the repair, and the kernel project has also published stable-tree backports. The defect is in
drivers/usb/gadget/function/f_midi.c, the code behind the
usb_f_midigadget module—not in the ordinary USB host-side MIDI stack used by desktop Linux systems.
For Windows users and Windows administrators, Windows itself is not affected. Nor does attaching a USB MIDI keyboard, synthesizer, or audio interface to a Windows PC create exposure. The relevant Linux code runs when a machine such as an embedded board, development device, custom appliance, or suitably equipped PC presents itself to another host over USB as a MIDI peripheral.
That distinction is important for WSL users, too. WSL 2 runs a Linux kernel, but a standard WSL installation is not automatically a USB gadget device and does not turn a Windows machine into a USB MIDI peripheral. A custom WSL kernel or specialized virtualized development setup deserves review only if it explicitly enables the gadget stack and uses the legacy MIDI gadget function.
The teardown race sits between USB and ALSA
The
f_mididriver creates a virtual ALSA raw-MIDI device and exposes it over USB through Linux’s composite-gadget framework. It has a deferred work item,
midi->work, used to handle inbound USB endpoint work. That work accesses the surrounding
struct f_midi; therefore, it must be stopped before the structure is released.
Before the fix, the driver could disable its USB endpoints and begin dismantling the gadget while an ALSA raw-MIDI substream remained open. A userspace process holding that substream could write during the teardown window. That write could enter
f_midi_in_trigger()and queue the same deferred work again after
f_midi_disable()had completed.
The driver then had two independent lifetime references to account for: one from the USB function and another tied to the raw-MIDI device. Once the final reference disappeared,
f_midi_free()could free the
struct f_midi. A scheduled or running work item could then execute and recover that now-invalid parent pointer with
container_of(), producing a kernel use-after-free.
The repair is small but placed at the correct lifetime boundary. The kernel patch adds
cancel_work_sync(&midi->work)in
f_midi_free()immediately before the final object release.
cancel_work_sync()both removes queued work and waits for an in-progress instance to finish, so the memory cannot be freed underneath its handler.
The advisory explicitly notes why cancelling during
f_midi_disable()would not close the hole: the ALSA-trigger path could queue work again after that function returned. Moving cancellation to the reference-count-zero path means neither the USB endpoint side nor the raw-MIDI side can still legitimately revive the work item.
A high local score does not make this a broad remote attack
Kernel.org assigned CVE-2026-64584 a CVSS 3.1 base score of 7.8, rated High, with local attack vector, low complexity, low privileges, no user interaction, and high impact across confidentiality, integrity, and availability. NVD has not yet issued its own CVSS assessment.
That score describes what a successful local kernel memory-corruption bug can mean in a susceptible configuration. It does not mean every Linux computer with MIDI support is vulnerable, and it does not describe a network-reachable Windows flaw.
The attack preconditions are meaningful:
- The system needs the USB gadget subsystem, a device-mode USB controller, and the legacy
f_midifunction available. - The MIDI function must be configured into an active USB gadget rather than merely compiled into the kernel.
- A local process needs access to the virtual ALSA raw-MIDI endpoint during a narrowly timed disconnect, disable, or unbind operation.
Linux’s own gadget documentation makes clear that a gadget must be composed through configfs and bound to a USB Device Controller before a host can enumerate it. The MIDI function is provided by
usb_f_midi.ko, and the relevant Kconfig option,
CONFIG_USB_CONFIGFS_F_MIDI, depends on the USB gadget configuration framework and sound support.
In practical terms, this is most relevant to embedded Linux devices that expose USB MIDI ports: single-board computers, audio and music hardware, test rigs, prototyping platforms, and custom appliances. A workstation that only operates as a USB host—the normal role for laptops and desktops—does not enter this driver’s execution path.
The affected-version record needs careful reading
NVD’s record currently contains an awkward version presentation that administrators should not treat as a clean patch matrix. It identifies Linux kernel versions from 5.12 onward as affected by default, while listing fixed stable lines including 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5.
But the same record also contains older affected-range entries associated with 5.4.291 and 5.10.235 that appear inconsistent with the separate statement that versions earlier than 5.12 are unaffected. This is exactly the sort of machine-generated CVE version data that should be checked against a distribution’s actual kernel source package and changelog rather than used as a blanket declaration that every 5.4 or 5.10 kernel is exposed.
The useful operational conclusion is straightforward: do not rely only on uname -r or an upstream version number where a vendor backports security fixes. Enterprise distributions commonly carry the correction in a vendor-maintained kernel package without changing the kernel’s upstream base version to one of the listed stable releases.
The upstream kernel record identifies five stable-tree commits for the correction, reflecting backports across maintained branches. Distribution maintainers should use those patches or their vendor-equivalent commits to verify remediation. There is no indication in the published record of exploitation in the wild, a proof-of-concept, or a remotely triggerable path.
What Linux and Windows administrators should check
For embedded Linux fleets and custom devices, the first task is to establish whether the legacy MIDI gadget function exists and is used. A running system can be checked with commands such as:
grep CONFIG_USB_CONFIGFS_F_MIDI /boot/config-$(uname -r)
find /sys/kernel/config/usb_gadget -type d -path '*functions/midi.*'
lsmod | grep usb_f_midiA built-in kernel will not necessarily show
usb_f_midiin
lsmod, and a configured-but-inactive gadget may not appear in configfs. Those commands are therefore triage signals, not a complete vulnerability scanner. Device build configurations, startup scripts, and any application that creates
functions/midi.*under
/sys/kernel/config/usb_gadget/provide the stronger evidence.
Administrators who find no
CONFIG_USB_GADGET, no
CONFIG_USB_CONFIGFS_F_MIDI, or no actual MIDI gadget configuration can deprioritize this CVE. Disabling the MIDI gadget feature where it is not needed also removes the vulnerable code path. Systems using the newer MIDI 2.0 gadget function,
usb_f_midi2.ko, are outside the submitted CVE’s scope; the flaw is specifically in the older
f_midiimplementation.
For managed Linux systems that do use the legacy function, install the vendor’s current kernel security update and reboot into it. Teams building their own kernels should incorporate the upstream stable backport and verify that
f_midi_free()synchronously cancels
midi->workbefore releasing the MIDI object.
The main consequence is not a Windows desktop emergency or a reason to disconnect USB MIDI peripherals. It is a targeted kernel-maintenance item for systems deliberately configured as Linux USB MIDI devices, where an unpatched teardown race can turn a local MIDI client into a path for kernel memory corruption.
References
- Primary source: NVD / Linux Kernel
Published: August 9, 2026 at 8:43 AM UTC
- Security advisory: MSRC
Published: August 9, 2026 at 8:43 AM UTC
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: docs.kernel.org
- Related coverage: codebrowser.dev
linux/linux/drivers/usb/gadget/function/ Source Tree
Code browser for C, C++, Rust & Dart
codebrowser.dev
- Related coverage: origin.kernel.org
MIDI 2.0 on Linux — The Linux Kernel documentation
origin.kernel.org
- Related coverage: cdn.kernel.org
- Related coverage: kernel.org
Gadget Testing — The Linux Kernel documentation
www.kernel.org
- Related coverage: codebrowser.dev
midi.h source code [linux/include/uapi/linux/usb/midi.h] - Codebrowser
Source code of linux/include/uapi/linux/usb/midi.h linux v6.19-r on KDAB Codebrowser
codebrowser.dev
- Related coverage: code.googlesource.com
- Related coverage: code.googlesource.com
