CVE-2026-31726: usb: gadget: uvc: fix NULL pointer dereference during unbind race
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: uvc: fix NULL pointer dereference during unbind race
Commit b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanly shutdown") introduced two stages of synchronization waits totaling 1500ms in uvcfunctionunbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions.
When the PM subsystem starts freezing user space processes, the waiteventinterruptibletimeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL):
[ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvcfunctionunbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvcfunctionunbind no clean disconnect, wait for release
When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic:
[ 814.292597][ C0] PM: pmsystemirqwakeup: 479 triggered dhdpciehostwake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usbgadgetdeactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usbfunctiondeactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usbgadgetdeactivate+0x14/0xf4 [ 814.404083][ T4558] usbfunctiondeactivate+0x54/0x94 [ 814.404087][ T4558] uvcfunctiondisconnect+0x1c/0x5c [ 814.404092][ T4558] uvcv4l2release+0x44/0xac [ 814.404095][ T4558] v4l2release+0xcc/0x130
Address the race condition and NULL pointer dereference by:
1. State Synchronization (flag + mutex) Introduce a 'funcunbound' flag in struct uvcdevice. This allows uvcfunctiondisconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'funcconnected' for consistent state management.
2. Explicit Synchronization (completion) Use a completion to synchronize uvcfunctionunbind() with the uvcvdevrelease() callback. This prevents Use-After-Free (UAF) by ensuring struct uvcdevice is freed after all video device resources are released.
Affected Software
Remediation
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux USB gadget UVC function are exposed when its unbind path can race with a power-management suspend transition and the V4L2 release path. The reported impact is a kernel panic, resulting in denial of service.
What access or conditions are needed to trigger the vulnerability?
The CVSS vector indicates local access and low privileges are required, with no user interaction. The failure depends on an unbind operation occurring while power management freezes user-space processes, followed by task restart and V4L2 release processing.
Is a default Linux installation known to be affected?
The available information does not establish that default configurations are affected. The vulnerable path specifically involves the USB gadget UVC function, so systems not using that functionality are not identified as exposed by the provided data.
How can administrators identify a possible occurrence?
Review kernel logs for UVC unbind activity during suspend, including messages such as "uvc_function_unbind no clean disconnect, wait for release," followed by a panic after the system resumes or aborts suspend. The described failure occurs when the V4L2 release path accesses a gadget pointer that has already been cleared.
What should be done to remediate it?
Apply the available Linux kernel patch. The provided references identify stable kernel commits containing the fix.