CVE-2026-31726

What it actually does

This is a local Linux kernel race condition in the USB gadget UVC function teardown path. During UVC gadget unbind, power-management suspend or resume can interrupt timing-based synchronization, allowing the gadget pointer to be set to NULL while the V4L2 release path later attempts to use it. The result is a NULL pointer dereference, and the related fix also addresses a use-after-free risk by synchronizing release of UVC video resources. The practical security impact is local denial of service through a kernel panic; confidentiality and integrity impact are not indicated by the published details.

Why it matters to the business

Systems using the Linux kernel USB gadget UVC functionality, such as embedded devices, appliances, development boards, Android-derived devices, cameras, or USB peripheral-mode systems, may crash when local users or local processes trigger UVC gadget teardown during suspend or resume activity. This can cause device reboots, service interruption, loss of active sessions, and operational instability. The CVSS availability impact is high, but current public exploitation likelihood appears low: EPSS is approximately 0.00119, the 30-day trend is flat, there is no known exploit maturity, and it is not listed in CISA KEV or known ransomware use.

How an attack unfolds

An attacker needs local execution capability or another way to influence local USB gadget/UVC configuration and power-management timing. They configure or use a USB UVC gadget, trigger an unbind or shutdown path for the UVC function, and then cause or wait for a suspend, resume, or aborted suspend transition while the unbind synchronization is in progress. Because the vulnerable kernel relies on timeout-based waits, freezing user-space tasks can cause the wait to end early. The unbind path can then nullify the gadget pointer before the V4L2 release path completes. When tasks restart, the V4L2 release path calls into the UVC disconnect logic and attempts to deactivate a gadget through the NULL pointer, causing a kernel NULL pointer dereference and panic. The expected outcome is a local system crash rather than code execution based on the available information.

How to fix it

Apply a vendor kernel update that includes the upstream fix for the USB gadget UVC unbind race. No exact fixed package versions were provided in the input, so use the distribution, device vendor, or kernel maintainer advisory to identify the corrected kernel build for each affected platform. Where immediate patching is not possible, reduce exposure by disabling USB gadget UVC functionality, removing unused UVC gadget configurations, restricting write access to USB gadget/configfs interfaces, limiting local shell or application access that can manipulate gadget state, and avoiding suspend/resume workflows on affected devices until patched. For embedded or appliance products, validate that downstream BSP or vendor kernels have backported the fix rather than relying only on upstream version numbers.

How to confirm the fix worked

Confirm the running kernel is a vendor build that contains the UVC gadget race fix, not merely a package with a newer name. Validate by reviewing vendor changelogs or kernel source for the addition of protected UVC device state such as a func_unbound flag, locking around UVC connected/unbound state, and completion-based synchronization between UVC function unbind and video device release. On test systems, reproduce the previously risky lifecycle safely by repeatedly starting and stopping a UVC gadget while exercising suspend, resume, and aborted suspend transitions; the system should not panic and kernel logs should not show NULL pointer dereferences in usb_gadget_deactivate, usb_function_deactivate, uvc_function_disconnect, or uvc_v4l2_release. Also confirm that unnecessary UVC gadget configurations are absent or disabled on systems that do not require them.

Typical attack path

1. Obtain local user-level access to a Linux system that exposes USB gadget UVC functionality.
2. Ensure a UVC gadget function is configured or active, commonly through USB gadget/configfs workflows.
3. Trigger UVC function unbind, gadget shutdown, or application cleanup for the UVC gadget.
4. Induce or race a system suspend, resume, or aborted suspend event while UVC unbind synchronization is pending.
5. Allow user-space tasks to restart so the V4L2 release path runs after the gadget pointer has been nullified.
6. Cause the kernel to dereference the NULL gadget pointer in the USB gadget deactivation path, resulting in a kernel panic or reboot.

How to detect it

To determine whether this was already exploited or triggered, review persistent kernel logs, system journals, crash dumps, pstore/ramoops records, kdump/vmcore data, device watchdog logs, and reboot reason telemetry. Focus on crashes occurring during or immediately after USB gadget UVC shutdown, configfs gadget unbind, suspend entry, user-space freezing, resume, or aborted suspend. Look for kernel panic traces showing NULL pointer dereference at or near usb_gadget_deactivate, usb_function_deactivate, uvc_function_disconnect, uvc_v4l2_release, or v4l2_release. Correlate these events with local user sessions, application logs that control UVC gadget operation, writes to USB gadget configfs paths, power-management events, and unexpected reboots. Because the vulnerability is a local denial-of-service issue, network-only indicators are not expected unless a remote management service indirectly triggers local gadget operations.

• uvc_function_unbind()
• uvc_function_unbind no clean disconnect, wait for release
• Unable to handle kernel NULL pointer dereference
• usb_gadget_deactivate
• usb_function_deactivate
• uvc_function_disconnect
• uvc_v4l2_release
• v4l2_release
• configfs-gadget
• PM: suspend entry
• Freezing user space processes
• Restarting tasks ...
• pm_system_irq_wakeup
• /sys/kernel/config/usb_gadget

What your security team should do

• Prioritize patching Linux systems that use USB gadget/peripheral mode with UVC camera functionality, especially embedded, kiosk, mobile, appliance, lab, and OT-adjacent devices where local crashes affect availability.
• Ask platform, firmware, and device vendors for the specific kernel build or BSP release that backports the UVC gadget unbind race fix.
• Inventory exposure by identifying systems with USB gadget/configfs enabled and UVC gadget functions configured.
• If patching is delayed, disable UVC gadget functionality or restrict access to interfaces used to create, bind, unbind, or control USB gadget functions.
• Monitor kernel logs and crash telemetry for NULL pointer dereferences involving UVC, V4L2 release, USB gadget deactivation, and suspend/resume events.
• Treat repeated crashes matching this call trace as potentially intentional local denial-of-service activity, even though current EPSS, KEV, and exploit-maturity signals indicate low public exploitation likelihood.
• For products shipped to customers, include regression tests that exercise UVC gadget teardown during suspend/resume and aborted suspend transitions.