A new Linux-kernel vulnerability, tracked as CVE‑2025‑40314, has been published: a use‑after‑free in the cdns3 USB gadget driver that can occur when the cdnsp gadget fails to initialize or during gadget exit, and upstream kernel maintainers have merged a compact fix into recent stable trees to ensure endpoints are freed before the gadget structure itself is released.
The vulnerability lives in the Cadence cdns3 USB gadget code — specifically in the cdnsp gadget paths used by some device and SoC integrations. The unsafe ordering appears in the __cdnsp_gadget_init and cdnsp_gadget_exit code paths where the gadget structure (pdev->gadget) could be freed before the gadget’s endpoint objects. Because endpoints are linked from the gadget via an ep_list, freeing the gadget first leaves dangling references; when the endpoints are later freed the kernel can dereference already‑freed memory, producing a classic use‑after‑free (UAF) in kernel space. Upstream maintainers fixed this by splitting the usb_del_gadget_udc operation into separate “del” and “put” steps so that cdnsp_gadget_free_endpoints runs before the final usb_put_gadget that frees the gadget structure. This is a robustness / memory‑lifetime bug in driver teardown code. In practice such defects most commonly manifest as kernel warnings, KASAN reports, oopses, or panics — producing an availability impact (denial‑of‑service or host instability). Because the defect is a UAF in kernel code, in theory a sufficiently skilled and fortunate attacker could use the primitive as part of a larger exploit chain that achieves code execution, but public evidence of reliable exploitation or published PoC code is not available at the time of disclosure. Multiple trackers classify the immediate impact as availability‑first while noting the theoretical potential for memory corruption escalation.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
The vulnerability lives in the Cadence cdns3 USB gadget code — specifically in the cdnsp gadget paths used by some device and SoC integrations. The unsafe ordering appears in the __cdnsp_gadget_init and cdnsp_gadget_exit code paths where the gadget structure (pdev->gadget) could be freed before the gadget’s endpoint objects. Because endpoints are linked from the gadget via an ep_list, freeing the gadget first leaves dangling references; when the endpoints are later freed the kernel can dereference already‑freed memory, producing a classic use‑after‑free (UAF) in kernel space. Upstream maintainers fixed this by splitting the usb_del_gadget_udc operation into separate “del” and “put” steps so that cdnsp_gadget_free_endpoints runs before the final usb_put_gadget that frees the gadget structure. This is a robustness / memory‑lifetime bug in driver teardown code. In practice such defects most commonly manifest as kernel warnings, KASAN reports, oopses, or panics — producing an availability impact (denial‑of‑service or host instability). Because the defect is a UAF in kernel code, in theory a sufficiently skilled and fortunate attacker could use the primitive as part of a larger exploit chain that achieves code execution, but public evidence of reliable exploitation or published PoC code is not available at the time of disclosure. Multiple trackers classify the immediate impact as availability‑first while noting the theoretical potential for memory corruption escalation. How the bug works (technical anatomy)
Where the lifetime ordering breaks down
The vulnerable sequence centers on the gadget object (often referenced as pdev->gadget in the driver) and the endpoint structures it maintains via an internal list. Correct teardown requires freeing or unlinking endpoints first, then releasing the gadget object itself. In the buggy paths, the gadget structure was released prematurely; later cleanup code iterated or freed endpoints using pointers that now pointed at freed memory, triggering the UAF.- The functions named in public advisories are __cdnsp_gadget_init (the initialization path) and cdnsp_gadget_exit (the teardown path).
- The root cause is a resource lifetime ordering mistake: freeing the container (gadget) before its contained elements (endpoints).
The fix: separate del/put and free endpoints first
The upstream patch changes the sequence so that the driver invokes the removal logic (the “del” phase) separately from the final put that releases the gadget object. This allows the explicit cdnsp_gadget_free_endpoints to run while the gadget still exists, safely cleaning endpoint structures before usb_put_gadget can free the gadget. The change mirrors a similar repair previously applied to other gadget drivers (for example, the DWC3 gadget code) where freeing the gadget structure was intentionally deferred until endpoints were released. Kernel commit references for the fixes are available in the stable kernel commit stream.Who is affected and exposure model
Affected components and builds
The flaw is in the in‑tree Linux kernel cdns3 gadget code. Whether a given system is affected depends on:- Kernel version and whether it includes the upstream commit(s) containing the fix.
- Kernel configuration: whether the cdns3 gadget driver is built in or provided as a module.
- Whether the gadget code is used or enabled on the target device (the gadget driver is used on certain embedded SoCs and device images; not all desktop/server kernels include gadget code in their default build).
Attack vector and prerequisites
- Attack vector: local or local‑adjacent. The bug is reachable via USB gadget lifecycle events — a malicious or buggy gadget initialization sequence, device attach/detach, or malformed gadget state can exercise the problematic paths.
- Privileges required: typically low to none in scenarios where an attacker can make the kernel bind/unbind a gadget, present a crafted peripheral, or influence gadget initialization (for embedded devices or VMs with USB passthrough). However, exploitation normally requires the attacker to be local or have the ability to present or control USB device attachment.
Practical risk profile
- Primary impact: availability — kernel oops, KASAN reports under debug kernels, kernel panics, or instability.
- Secondary impact: theoretical potential for memory corruption escalations, but there is no public, reliable PoC showing remote code execution from this specific UAF at time of disclosure. Public EPSS values are very low, and the CVE is not listed among actively exploited vulnerabilities. Administrators should treat this as a reliability/stability defect with a moderate risk of later escalation in specialized threat models.
Detection and mitigations for defenders
What to look for in logs and telemetry
- Kernel logs containing KASAN traces or slab‑use‑after‑free messages referencing cdns3, cdnsp, gadget, or endpoint functions.
- Oops/backtrace output that includes cdnsp_gadget_exit, __cdnsp_gadget_init, or endpoint free functions.
- Unexpected reboots, QEMU / VM crashes (if USB gadget passthrough is used), or device driver warnings during USB disconnect/exit sequences.
Short-term mitigations when patching is delayed
- If a host does not require gadget functionality, unload or blacklist the cdns3/gadget modules to remove the code path entirely (recognize this may disrupt device‑specific features). On many systems that will be modprobe -r cdns3 (or adding a blacklist entry).
- Reduce or block USB gadget attach from untrusted sources: disable USB passthrough in virtualization hosts, restrict which devices can be attached, and enforce strict device allowlists for critical systems.
- For embedded appliances, contact the hardware or OEM vendor for fixed firmware/kernel images; for vendor kernels, wait for vendor backports or apply a trusted upstream patch and rebuild if feasible.
- Increase kernel logging and retention during the patch window; set alerts for KASAN and oops signatures.
Patch and remediation steps (recommended)
- Identify affected kernels: check your distro/security tracker and map installed kernel package versions to the advisory/commit range. Use uname -r and package metadata to determine whether your kernel contains the upstream fix. Debian, SUSE and other trackers list per‑release status.
- Apply vendor or distribution kernel updates that include the upstream stable commit(s) fixing CVE‑2025‑40314.
- Reboot hosts into the patched kernel to complete the remediation (kernel fixes require a reboot to take effect).
- Validate remediation: reproduce prior repro steps in a test lab (if you have representative devices), and verify dmesg no longer shows the previous KASAN/oops traces.
Operational impact and vendor response
Vendor trackers and vulnerability databases quickly indexed the CVE and linked to the stable kernel commits that implement the fix; Tenable and several distro trackers assigned severity values (Tenable lists a CVSSv3 figure that many trackers use as a guideline) and included the kernel commit references. Administrators should rely on their distribution’s security advisory for the canonical mapping of package versions to fixes. For embedded, vendor‑supplied, or out‑of‑tree kernel builds, expect a longer patch cadence: these ecosystems often maintain forked kernel trees and must backport the upstream patch manually. These devices are the highest operational risk because they may run older kernels and have bespoke device configurations. Contact OEM vendors for patched kernel/firmware images and timelines.Analysis: strengths of the upstream response and residual risks
Notable strengths
- The fix is surgical and low risk: it changes only the teardown ordering and mirrors established fixes applied elsewhere in the USB gadget stack, minimizing the likelihood of regressions.
- Upstream maintainers merged stable commits and multiple downstream trackers have already enumerated package statuses, enabling rapid detection and remediation via normal vendor update channels. References to the specific stable commits are visible in the advisory metadata.
- Public coverage by distro trackers (Debian, SUSE, etc. and security vendors provides administrators clear guidance on which package versions are affected and where fixed packages are available.
Residual and operational risks
- Exploitability ambiguity: While the immediate operational impact is availability, UAFs in kernel space historically can be escalated into more serious memory‑corruption exploits given additional primitives (heap grooming, info leaks, predictable allocator behavior). There is no public PoC for reliable RCE from this specific defect as of publication, but defenders should remain cautious.
- Vendor lag for embedded/OEM devices: appliances, custom boards, and long‑lived embedded images may take weeks or months to receive backported fixes — these are precisely the environments where gadget drivers remain relevant and patching is slow. Inventory and vendor engagement are essential.
- Detection blind spots: not all production kernels enable KASAN or verbose kernel logging, so silent failures (or crashes that cause service restarts without detailed traces) may be difficult to diagnose without proactive log collection. Centralized kernel logging and longer retention help close that gap.
Practical checklist for administrators (actionable)
- Inventory
- Run uname -r and check whether the kernel configuration or modules include cdns3. Confirm with modinfo cdns3 or grep CONFIG_USB_GADGET in your kernel config.
- Map to advisories
- Consult your distro’s security tracker (Debian, SUSE, Ubuntu, Red Hat) for the CVE mapping to package versions and fixed releases.
- Patch and reboot
- Install vendor kernel updates that include the upstream stable commits for CVE‑2025‑40314, then reboot.
- Mitigate if you cannot patch immediately
- Unload/blacklist cdns3 gadget modules where gadget functionality is unnecessary; disable USB passthrough on hypervisors; restrict USB device attachment.
- Monitor
- Enable and collect kernel logs, search for KASAN and oops patterns mentioning cdns3/cdnsp, and set SIEM/EDR alerts for the signatures described earlier.
What remains unverified / cautionary notes
- There is no authoritative public proof‑of‑concept for arbitrary code execution from CVE‑2025‑40314 in the wild as of the advisory publication. Published metrics (EPSS) are low and the CVE is not listed on exploitation watchlists at the time of writing; nevertheless, UAFs in kernel drivers should be treated seriously because of their potential to be chained into more powerful exploits. Treat exploitation claims cautiously and rely on vendor advisories for remediation guidance.
Conclusion
CVE‑2025‑40314 is a well‑scoped but meaningful Linux‑kernel gadget driver bug: a lifetime ordering error in the cdns3 cdnsp gadget that produced a use‑after‑free during failed initialization and exit. The upstream fix is concise — ensure endpoints are freed before the gadget object is released — and has been merged into the stable kernel trees. For defenders the practical priorities are: determine whether your kernels include the cdns3 gadget, apply vendor kernel updates (and reboot) as soon as feasible, and, where immediate patching is not possible, remove or restrict gadget code and tighten USB/device attachment policies until you can deploy the fix. Kernel logs, KASAN traces, and distribution security trackers are the right telemetry sources to validate both exposure and remediation.Source: MSRC Security Update Guide - Microsoft Security Response Center
