This is a use-after-free in the Linux kernel's USB core, where the sysfs read path for USB device BOS descriptors races against device reset logic that frees the same data structure. The vulnerability is technically severe (CVSS 7.8) but appears rarely exploited in the wild (EPSS 0.00128), which warrants explanation rather than dismissal.
The race lives at the boundary between two independently-evolved kernel subsystems: the USB core's reset machinery and the driver model's sysfs interface. The bos_descriptors_read() function serves userspace reads from /sys/bus/usb/devices/*/ descriptors/bos, while usb_reset_and_verify_device() tears down and reinitializes USB device state including the BOS descriptors. These code paths never coordinated on locking, because they were written for different purposes at different times by different maintainers. The fix is simple — adding synchronization — but the simplicity is the endpoint of diagnosis, not evidence the bug was obvious. Choosing the wrong lock type could introduce deadlocks or contention across the USB subsystem, which is why the fix required understanding both subsystems' locking assumptions.
The sysfs attack surface changes the exploitation calculus. Local unprivileged users can trigger this race without special privileges — they simply need to be reading sysfs attributes while a device reset occurs, which happens during normal hotplugging, driver rebinding, or even benign device operations. You don't need to engineer the race; you need to be in the right place when the kernel does something ordinary. This makes the vulnerability accessible to any local user, even though reliable exploitation requires precise timing.
The historical pattern is worth noting: this is the same race class as CVE-2011-0522 (dvb-core), CVE-2014-9718 (device property), and CVE-2019-20636 (input). The kernel has seen this mutation repeatedly at different subsystem boundaries, suggesting the coordination failure between independently-maintained code paths is a systemic pattern, not a one-off.
The low EPSS likely reflects that kernel heap exploitation has gotten harder (SLAB hardening, KASLR) and that reliable timing automation for this race is non-trivial — not that the vulnerability is harmless. The blast radius extends through every USB driver that calls the reset path, meaning a successful exploit could corrupt memory visible to drivers across the entire USB subsystem.
Check whether your kernels are patched. If you run systems with untrusted local users who have USB device access, prioritize this patch — the combination of sysfs accessibility, use-after-free severity, and the history of similar races argues for treating this as a real risk despite the low EPSS.