CVE-2026-63927

What it actually does

This is a use-after-free flaw in the Linux kernel USB DWC2 host controller driver debug path. The driver calls usb_hcd_giveback_urb(), which returns ownership of a USB request block and may free or otherwise invalidate it, then later dereferences the same URB to read its status for debugging. A local attacker with access to the affected USB/DWC2 path may be able to trigger stale kernel memory access, causing a kernel crash or, depending on memory layout and exploitability on a given build, potentially escalating privileges or corrupting kernel memory. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could let a local user or compromised local process destabilize affected Linux systems, cause outages through kernel crashes, or potentially gain elevated privileges. This is most relevant to systems using the Synopsys DesignWare USB 2.0 controller driver, including embedded Linux devices, appliances, ARM-based platforms, development boards, and other systems where the dwc2 driver is enabled. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local privilege escalation bugs in the kernel should still be prioritized on multi-user systems and devices exposed to untrusted local code or USB interactions.

How an attack unfolds

An attacker first needs local execution capability or another path that lets them interact with the affected USB/DWC2 driver code. They then trigger USB activity that causes the driver to complete a URB through usb_hcd_giveback_urb(). In the vulnerable code path, the driver later reads a field from that URB after ownership has been returned and the object may already be freed or reused. In the simplest case, this produces a kernel oops, panic, or denial of service. With favorable kernel heap grooming, timing, and build conditions, an attacker may attempt to reclaim the freed memory with controlled data so the stale dereference influences kernel behavior, potentially supporting privilege escalation or memory disclosure. No public exploitation or named threat actor activity is currently reported for this issue.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or device vendor that includes the upstream fix for the DWC2 use-after-free condition. No exact fixed package versions were provided in the input, so use vendor advisories and kernel changelogs to identify patched builds containing the change that saves the URB status before calling usb_hcd_giveback_urb(). Where immediate patching is not possible, reduce exposure by disabling or unloading the dwc2 driver if it is not required, disabling unused USB functionality in firmware or kernel configuration, restricting local shell/container access on affected devices, and limiting physical or logical access to USB interfaces. Rebuild custom kernels with the corrected driver source and standard kernel hardening options such as KASAN/KFENCE for testing, hardened slab allocator settings where available, module signing, lockdown mode, and least-privilege controls for local users.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or custom kernel source includes the DWC2 patch that stores urb->status before usb_hcd_giveback_urb() and does not dereference the URB afterward. Check whether the driver is present or active using commands such as lsmod | grep dwc2, modinfo dwc2, grep DWC2 /boot/config-$(uname -r), and inspection of /sys/bus/platform/drivers/dwc2 where applicable. For distribution kernels, confirm the installed kernel version matches the vendor-fixed release and that the system has rebooted into that kernel. For custom builds, review the relevant drivers/usb/dwc2 source and run regression testing with USB host functionality enabled. Exposure is reduced if the affected driver is not built, not loadable, or not used on the platform, but patching remains preferred for general-purpose kernels.

Typical attack path

1. Obtain local code execution on a system running an affected Linux kernel with the dwc2 USB host controller driver enabled or loaded.
2. Determine whether the target exposes the affected DWC2 USB path, such as through embedded USB controller functionality or relevant kernel modules.
3. Trigger crafted or high-rate USB operations that drive URB completion through the vulnerable debug code path.
4. Cause the driver to call usb_hcd_giveback_urb() and then dereference the invalidated URB status field.
5. Use the resulting stale memory access to crash the kernel, or attempt heap grooming to turn the use-after-free into privilege escalation or kernel memory corruption.

How to detect it

Look for evidence of prior exploitation primarily in kernel logs, crash dumps, and endpoint telemetry because this vulnerability occurs inside kernel USB driver code and is unlikely to leave application-level artifacts. Review journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore records, and appliance support bundles for kernel oops, panic, KASAN, KFENCE, or slab use-after-free reports involving dwc2, USB host controller activity, URB completion, or usb_hcd_giveback_urb(). Correlate crashes with local login sessions, container workloads, device attachment/removal events, USB fuzzing tools, or unusual processes interacting with USB devices. On systems with auditd or EDR, review local privilege escalation attempts around the time of kernel instability, including new root shells, suspicious setuid file creation, kernel module loading attempts, and unexpected changes to persistence mechanisms. Because no public exploit or threat actor activity is currently known, detection should focus on anomalous kernel memory errors and repeated USB-triggered crashes rather than fixed malware indicators.

• BUG: KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• KFENCE: use-after-free
• use-after-free in dwc2
• dwc2
• usb_hcd_giveback_urb
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• general protection fault
• kernel panic
• Oops:
• URB
• drivers/usb/dwc2

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and custom kernels that include or load the dwc2 USB host controller driver.
• Prioritize patching systems where untrusted users, workloads, containers, or physical USB access are possible, especially multi-user servers and managed appliances.
• Track vendor kernel advisories and upgrade to a fixed kernel build; ensure systems are rebooted after kernel update.
• For systems that cannot be patched quickly, disable unused USB/DWC2 functionality or restrict access to USB interfaces and local execution paths.
• Review kernel crash, oops, and KASAN logs for signs of use-after-free activity involving USB, dwc2, URB handling, or usb_hcd_giveback_urb().
• Treat unexplained kernel crashes on affected devices as potentially security-relevant until patched and reviewed.
• For custom kernel maintainers, cherry-pick the upstream fix and add regression coverage around URB completion in the dwc2 driver.