CVE-2024-46674: Linux st_dwc3 USB driver refcount bug fixed

A subtle mistake in the Linux USB driver stack has been quietly corrected — and the fix exposes a classic kernel problem: an erroneous decrement of a platform device reference count in the DesignWare Core USB3 (dwc3) ST driver that can lead to use‑after‑free and service loss. The vulnerability cataloged as CVE‑2024‑46674 stems from the probe error path in the st_dwc3 driver: the error handler attempts to undo a platform device allocation that never happened, dropping the refcount of the platform device being probed. That misstep can leave device reference counts unbalanced, cause premature release of devm‑managed resources, and open the door to memory corruption, kernel crashes, and potentially privilege escalation for attackers who can trigger the faulty path.

Background / Overview​

The Linux kernel's USB subsystem includes the DesignWare Core USB3 (dwc3) driver family, which supports a range of SoC vendors and platform bindings. One of those bindings — the ST (STMicroelectronics) dwc3 port, commonly named st_dwc3 in kernel sources — contains code that runs when the kernel "probes" the platform device (that is, the controller instance is initialized and bound to its driver).
During device initialization, the probe function must allocate resources and register managed allocations with the kernel's device‑management helpers (devm_ APIs) so that failures unwind cleanly. The probe function also needs to handle errors correctly: if one step fails, the code should only undo the actions it actually performed. In CVE‑2024‑46674 the probe error path mistakenly runs an "undo" routine that decrements the platform device reference count even though the probe did not allocate that device. The result: an unbalanced refcount and a premature release of device resources that other devm code still expects to exist. When the kernel later attempts to free remaining devm‑managed resources, it can hit a use‑after‑free condition — a critical class of memory corruption bugs in kernel space.
This defect was fixed upstream in the stable kernel trees and backported into several release branches. The vulnerability was assigned a high severity (CVSSv3 base score 7.8) because a successful attack can result in memory corruption with high confidentiality, integrity, and availability impact. The attack vector is local* (the attacker must be able to trigger the probe error path on the affected system), and the privileges required are considered low for local access scenarios.

---

How the bug works: technical anatomy​

Device probing, devm, and reference counts — a quick primer​

When the kernel binds a driver to a device, the probe routine runs initialization code:

• It acquires resources: memory regions, clocks, regulators, IRQs, platform device references, and more.
• Developers often use device-managed helpers (the devm_* family) to register allocations that the kernel will automatically free when the device is torn down.
• The kernel uses reference counting for core objects like struct device; each acquisition should be matched by a release so device resources remain valid until all users are done.

A correct probe error path must only undo resources the probe actually acquired. Unwinding must be symmetrical.

The specific mistake in st_dwc3​

In the st_dwc3 probe path the error handling included a call to an "undo_platform_dev_alloc" routine. But the probe function never allocates a separate platform device instance that needs undoing — it operates on an existing platform device passed in by the platform bus. Calling the undo routine therefore decremented the reference counter on the platform device being probed.
Consequences of that incorrect decrement sequence:

• The platform device's refcount falls lower than expected.
• Some devm-managed resources remain registered but the underlying device object may be prematurely released.
• When the kernel later releases those devm-managed resources, it may access memory the kernel has already freed — a use‑after‑free.
• Use‑after‑free in kernel space can manifest as kernel oops/panic (denial of service), data corruption, or — in nuanced exploitation chains — code execution with elevated privileges.

Why this is more than a simple crash​

This is not just a one-off bug that causes a tidy probe failure. Because the error path is executed in certain failure scenarios, a local attacker who can reliably trigger that failure can cause repeated unbalanced refcount events. Over time or repeated triggers, the system may suffer:

• Sustained denial of service (kernel oops or panic that brings down the kernel or key services).
• Persistent condition where device resources are inconsistent, causing service instability for USB subsystems and anything that depends on them.
• In the worst case, memory corruption that an adversary might chain into privilege escalation. That requires greater sophistication and favorable memory conditions, but it cannot be dismissed.

---

Scope and affected systems​

CVE‑2024‑46674 is a Linux kernel vulnerability in the st_dwc3 USB binding. The defect has been addressed across the upstream stable trees and has been backported to many vendor kernels and distribution kernels. The patch appears in stable release notes and vendor advisories for multiple kernel versions, and vendors have included the fix in a number of distribution updates.
Key points you need to know:

• The vulnerable code exists in the dwc3 st binding for the Linux kernel. Systems that do not use the st_dwc3 driver (i.e., don't run ST's dwc3 hardware binding) are not affected.
• The issue was fixed in upstream stable trees and then merged across many supported kernel branches; vendors issued security updates to distribute the patched kernels.
• The reported CVSSv3 base score is 7.8 (High), with an attack vector of local and low required privileges.
• Exploitation requires the ability to trigger the probe error path — which typically means local access or the ability to influence kernel probing (e.g., by hotplugging devices, manipulating device tree on some embedded setups, or interacting with direct hardware on systems with accessible USB controllers).

Because the driver is present mainly on systems using STMicroelectronics variations of the DesignWare USB controller (common in embedded platforms and some ARM SoCs), the most impacted systems are:

• Embedded Linux devices that use ST-based dwc3 bindings (routers, IoT gateways, industrial controllers).
• Vendor-specific distributions and kernels (Android kernel trees, custom embedded kernels).
• Servers and desktop distros that received the backported fixes in vendor kernels are protected once updated; unpatched systems with affected hardware remain at risk.

---

Real-world exploitation: risk assessment​

No credible public exploit for CVE‑2024‑46674 had been published as of February 18, 2026. That does not mean the risk is negligible.
Attack complexity and likely scenarios:

• Attack complexity: moderate. The attacker must cause the probe error path to run reliably, which depends on hardware and the driver init sequence.
• Privileges required: local or physical. Triggering the probe error path typically requires local access, the ability to cause device enumeration events, or the insertion of a specially crafted peripheral or firmware that provokes the driver’s error path.
• Consequences of a successful exploit: high. Memory corruption may lead to kernel panics (denial of service) or, in a carefully crafted chain, privilege escalation and arbitrary kernel code execution.

Notable exploitation vectors:

• Malicious USB peripheral that triggers an error during controller probe or reinitialization.
• Carefully timed hotplug events that cause a probe failure path in systems that re-probe controllers during runtime.
• Local software (possibly with limited privileges) that can interact with hardware platform bindings in unusual ways on embedded systems where device tree or platform registration is more malleable.

Given these conditions, enterprise servers running mainstream distributions are less likely to be trivially exploited unless they use the affected ST binding and present the right hardware configuration. Embedded devices, industrial equipment, and IoT devices are comparatively higher risk due to tighter hardware coupling and long-lived unpatched kernels.

---

Detection, indicators, and diagnostics​

Detecting evidence of attempts or impacts related to CVE‑2024‑46674 requires attention to kernel logs and device behavior. Look for:

• Kernel oops or panic messages that mention st_dwc3 or dwc3 in call traces.
• dmesg lines indicating probe errors for the ST dwc3 platform device, including messages printed by the probe routine during initialization or error unwinding.
• Repeated USB subsystem failures after hotplug events, or devices that fail to enumerate reliably.
• Ongoing crashes or instability of services that use USB devices (e.g., USB storage, serial interfaces, or composite devices).

Suggested diagnostic steps:

• Inspect the kernel ring buffer: run dmesg or journalctl -k and search for st_dwc3 or dwc3 related messages.
• Check for module presence: list loaded modules and kernel config for the st binding. In some systems the st driver is built-in rather than modular.
• Identify platform hardware: query the system’s device tree or platform bindings to determine whether the ST dwc3 driver is in use.

If you see repeated probe failure logs or use‑after‑free like backtraces that mention dwc3 or st, treat that as a high‑priority incident to remediate.

---

Mitigation and remediation​

Patch the kernel — this is the primary and recommended remediation. Distribution vendors have released updated kernels containing the fix. Prioritize updates as follows:

• Apply vendor-supplied security updates to your kernel packages immediately. This is the safest and simplest route for most organizations.
• For embedded devices where vendor updates are not available, obtain patched kernel sources from upstream stable trees, apply the upstream patch locally, and rebuild kernels or contact your device vendor for updated firmware.
• If you cannot update promptly, consider temporary mitigations:
• Disable or blacklist the st_dwc3 driver module if your hardware does not need that driver. Note this may disable USB functionality for controllers using that binding.
• Avoid connecting untrusted USB devices to systems with affected kernels.
• For managed environments, restrict physical access and enforce strict device connection policies.

Blacklisting example (temporary, may require reboot):

• Add the driver name to module blacklist configuration and update initramfs as needed. Remember that blacklisting a module on systems where the driver is built into the kernel is not possible — in that case an update or vendor action is required.

For embedded products and appliances:

• Contact the vendor for a patched firmware/kernel image.
• If you are the maintainer, fetch the upstream stable patch and backport to your vendor kernel, rebuild, and test thoroughly.

---

Recommended remediation checklist​

• Inventory: Identify systems with ST dwc3 hardware or the st_dwc3 binding.
• Patch: Prioritize kernel updates from your distribution vendor or vendor-provided firmware updates.
• Monitor: Watch kernel logs for signs of probe failures or oops messages mentioning dwc3/st.
• Restrict: Limit physical and local access to systems that cannot be immediately patched.
• Test: On devices that must be updated manually, test patched kernels in staging before broad deployment.
• Report: If you see evidence of exploitation, collect logs and follow your incident response processes.

---

Why this bug matters: broader lessons​

CVE‑2024‑46674 is an instructive example of how error-path code — code that runs only when something else fails — can introduce severe vulnerabilities. A function that appears harmless in an edge case can cause memory safety violations when developers assume a resource was allocated when it wasn’t.
Three broader takeaways:

• Error-handling code deserves the same level of scrutiny and testing as the successful path. Unbalanced allocations and undos are fertile ground for refcount and double‑free/UAF bugs.
• Device-managed helpers (devm_*) simplify resource cleanup but hide coupling between device lifetimes and allocations. If the release order or refcounting is wrong, devm can cause surprising accesses to freed memory.
• Backporting fixes across many kernel trees and vendor kernels is essential — devices in the field, especially embedded devices, often run long‑lived kernels and may remain unpatched for years, increasing the window of exposure.

---

Critical analysis: strengths and remaining risks​

The fix itself is straightforward — remove or correct the erroneous refcount decrement in the probe error path and ensure symmetric resource management. Upstream maintainers merged the fix into stable trees and vendors packaged kernel updates. That rapid triage and stable‑tree backporting is a strength of Linux kernel maintenance processes.
However, several risks remain:

• Many embedded devices and appliances run forks or vendor kernels that are slow to receive fixes. Those devices may remain vulnerable for long periods.
• Detection can be noisy. Kernel oops messages and USB errors may be attributed to flaky hardware rather than a systematic refcount problem, so incidents can be underreported.
• Exploitation chains in the kernel are often possible when a crafty attacker combines multiple, distinct issues. While CVE‑2024‑46674 by itself requires a local or physical trigger, it could be combined with other vulnerabilities to yield more powerful escalation paths.
• Blacklisting the driver as a temporary mitigation can be operationally disruptive: systems that need USB connectivity will lose it, so it is not a one-size-fits-all workaround.

In short: the fix plugged a real memory‑safety hole, but the ecosystem challenge — keeping long‑lived kernels patched and ensuring embedded vendors deliver firmware updates — is the larger systemic problem.

---

Practical advice for system administrators and developers​

For sysadmins:

• Treat this as a high‑priority kernel patch if any of your systems use ST dwc3 hardware or run kernels known to include the st binding.
• Test vendor kernel updates in a staging environment where USB peripherals and controller behavior can be verified.
• Add kernel probe and USB subsystem checks to your regular monitoring and alerting to catch suspicious probe failures early.

For embedded device developers:

• Audit probe and error handling code paths in drivers you maintain. Make sure each "undo" corresponds to an explicit "do".
• Where possible, prefer defensive coding patterns: check allocations before decrementing refcounts and add unit tests that simulate error conditions.
• Build a vendor patching plan for deployed devices and communicate expected update timelines to customers.

For security teams:

• Include USB subsystem anomalies in threat hunting playbooks; a successful local exploitation attempt may first surface as repeated probe failures or device disconnects.
• Coordinate with hardware teams to restrict physical access to high‑value endpoints until they are patched.

---

Conclusion​

CVE‑2024‑46674 illustrates a deceptively simple but dangerous class of kernel bugs: an erroneous refcount decrement in an error path that results in use‑after‑free conditions. The vulnerability impacts the st_dwc3 binding in the Linux dwc3 USB driver family and has been fixed in upstream and vendor kernels. Organizations with ST‑based DesignWare USB controllers — particularly embedded and IoT deployments — should prioritize kernel updates, monitor kernel logs for probe errors, and apply mitigations where necessary.
Fixing the defect was straightforward; the harder work remains keeping the vast and varied landscape of Linux deployments patched and secure. The kernel community’s rapid backporting and vendor advisory updates are positive, but the real measure of success will be how quickly those fixes reach the many embedded devices and vendor kernels still in the field. Until then, vigilance, timely patching, and conservative device‑connection policies are the best defenses against exploitation and denial‑of‑service stemming from this defect.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center