A late probe failure in the Linux kernel’s MOST USB stack has been tracked as CVE-2025-68290 and patched after maintainers fixed a double-free and related use-after-free paths that could crash systems or, in the worst case, be abused for memory-corruption attacks.
Background
The vulnerability lives in the
MOST (Media Oriented Systems Transport) USB driver code paths where device registration and error handling interact in non‑standard ways. The MOST subsystem uses a registration routine that frees the USB interface both on registration failure and on deregistration. A sequence of recent changes exposed a reference-count underflow and use-after-free which then manifested as several
double free conditions and additional use-after-free cases during
late probe failures. Multiple vulnerability trackers (NVD, OSV, distro security trackers) have cataloged the issue and linked it to a small, targeted patch in the kernel staging drivers that corrects the error paths. Distribution maintainers have started rolling the fix into kernels and backports for supported releases.
Overview of the defect and why it matters
What went wrong
At a high level, the bug is an error‑handling / reference counting flaw in drivers/most/most_usb.c that allowed the same resource to be freed more than once when probe failed late in initialization. Double frees and use-after-free lead to undefined behavior in C: kernel crashes (oops/panic), data corruption, and — in some cases where the memory layout and exploitation technique permit — escalation to arbitrary code execution from kernel context. The specific sequence here arises when the MOST registration function frees the interface on both failure and normal deregistration, and subsequent probe paths attempted to free or put devices again.
Realistic impact for administrators
- Crash/Denial-of-Service (DoS): The most immediate, credible impact is system instability or kernel oops/panic when vulnerable code paths run. The SUSE advisory rates the issue as moderate with a primary availability impact, consistent with a DoS risk.
- Memory corruption / potential escalation: Double-free and use-after-free are memory‑corruption classes that, under the right circumstances, can be leveraged for privilege escalation. Public advisories do not show active in‑the‑wild exploitation for this specific CVE at time of writing, but the class of bug is high-risk if an attacker can influence object lifetimes and memory layout. This must be treated as a condition that could be weaponized in targeted scenarios.
- Attack vector: According to distribution assessments, the vulnerability is a local issue (attack vector: local). That is, an attacker typically needs local access or to cause a vulnerable driver probe to execute (for example, by connecting a crafted USB/MOST device). The SUSE assessment models the attack as requiring low privileges but local access.
Technical analysis: root cause and the patch
Root cause, explained simply
The kernel’s MOST USB driver used a registration function with a
non-standard behavior: it freed the USB interface both if registration failed and when the interface was deregistered later. A small set of changes elsewhere in the driver chain accidentally turned existing reference-count underflows and a prior use-after-free into multiple double-free situations during late probe error handling. In short: inconsistent ownership and cleanup ordering produced attempts to release the same resource more than once.
What the fix changes in code
The applied patch addresses the error paths by simplifying the probe failure flow and eliminating duplicate frees. Key changes from the patch include:
- Early returns on registration failure rather than jumping to shared error cleanup labels that would free resources twice.
- Explicitly calling put_device in a probe branch immediately before calling most_deregister_interface when the device registration fails — ensuring the correct release sequence instead of leaving the responsibility to a later cleanup path.
- Removing legacy error labels that tried to free the same resources from multiple places, thereby eliminating the double-free sequences.
These changes were applied to drivers/most/most_usb.c in a small, surgical patch submitted to the stable tree. The patch replaces goto-based cleanup in the failing paths with immediate returns and adds a targeted put_device to balance references before deregistration. The maintainer notes reference a set of earlier commits that inadvertently exposed the flaw and explicitly list the fixes that the new patch corrects.
Why the code-level fix is sufficient
The patch removes the root cause —
conflicting ownership semantics — by making the failure path behavior consistent and balanced. By ensuring the probe function does not fall through into shared cleanup code that was also used by deregistration logic (which already freed the interface), the double free condition cannot occur. The change is localized and does not restructure the subsystem wholesale, which limits regression risk but requires careful review to ensure no edge cases were missed.
Affected kernels and distribution status
Multiple vulnerability trackers recorded the CVE and the relevant kernel commits; distribution trackers list affected and fixed package versions.
- The CVE entry and multiple trackers mark the issue as present in the upstream Linux kernel before the stable fix was applied. The official CVE record was created and published in mid‑December 2025.
- Debian’s security tracker lists patches and fixed package versions (for example, fixes rolled into specific 5.10 stable packages such as 5.10.247‑1), showing that maintainers have backported corrections for long‑term support kernels. Administrators running Debian LTS kernels should check the security tracker for the exact patched package numbers that apply to their suite.
- Ubuntu and SUSE published entries confirming the vulnerability and the resolution; SUSE provides a CVSS‑style assessment (base score ~5.5 under their calculation) and rates the issue as moderate with local attack vector and high availability impact. Ubuntu lists the CVE page and distribution status for affected series.
If you run custom kernels, the upstream stable commit(s) that implement the fix are small and straightforward to cherry‑pick; distributors that ship kernel packages will include these fixes in their next re‑build or provide backports for LTS tracks.
Exploitability, likelihood, and current evidence
- Exploitability: The vulnerability is a local memory‑corruption condition which is non‑trivial to exploit remotely unless an attacker can cause the vulnerable probe path to run with controlled inputs (for example, by connecting a malicious or specially crafted MOST USB device). The underlying memory corruption class (double free / use-after-free) is a known route to serious exploitation when combined with precise heap grooming. SUSE’s scoring denotes the attack vector is local and attack complexity is low, but confidentiality/integrity impacts are assessed as none while availability is high. This indicates the conservative assessment expects DoS as the most likely outcome.
- Public exploitation: As of the available advisories and databases consulted, there are no confirmed reports of active exploitation in the wild for CVE‑2025‑68290. Security trackers and Nessus plugin databases flagged the vulnerability and the need for vendor patches, but do not list any public PoC or active exploitation. That said, lack of public exploitation does not guarantee the vulnerability has not been used in targeted attacks; local, targeted weaponization can occur without public disclosure.
- EPSS / prioritization: Public scoring services report a very low EPSS estimate for this CVE (reflecting low observed exploit activity), but distribution advisories still mark the issue as moderate and have rolled out fixes — an expected posture for a memory‑corruption issue even if active exploitation is not yet observed. Administrators should balance the EPSS against local exposure and threat models.
Recommended actions for sysadmins and developers
The single most effective action is to apply the kernel updates that include the stable patch or backported fixes from your distribution. For organizations managing many systems, follow the steps below.
- Identify affected systems.
- Check kernel versions and whether the MOST staging driver is present or loaded (drivers/most). Look for modules named like most or examine dmesg for MOST/USB probe messages. If you do not use MOST devices or drivers, exposure is lower but the kernel still contains vulnerable code unless patched.
- Apply vendor patches or upgrade the kernel.
- For Debian, upgrade to kernel package versions that contain the fix (Debian’s tracker lists fixed versions such as 5.10.247‑1 for the older stable branch). For Ubuntu, SUSE, Red Hat or other distros, apply the kernel updates provided by the vendor for your release. If running a custom kernel, pull the stable commit (the patch is small) and rebuild.
- If you cannot patch immediately, mitigate exposure.
- Avoid connecting untrusted MOST USB devices to vulnerable hosts.
- Where feasible, unload or blacklist the MOST USB driver module (if your workflow does not require it) to eliminate the probe path from executing. This is a temporary mitigation and may not fully remove risk if the module is compiled into the kernel.
- Test and roll out.
- As with any kernel change, test patched kernels in a staging environment before broad deployment. The fix is small and targeted, but test for regressions in device enumeration and MOST‑related functionality.
- Monitor for vendor advisories and public exploit reports.
- Keep an eye on your OS vendor’s security advisory channels for updated guidance and additional backports. If you see unusual USB device behavior, kernel oopses referencing drivers/most, or repeated device registration/deregistration failures, treat them as high priority for investigation.
Developer guidance: reviewing and backporting the fix
For distribution and kernel maintainers the patch is small but must be applied carefully to backports. Key guidance:
- Preserve the ownership semantics introduced by the fix (early returns and explicit put_device calls) when backporting to older trees. Do not reintroduce shared cleanup labels that free resources in multiple contexts.
- Run kernel selftests and relevant USB/MOST functional tests after backporting to confirm no device initialization regressions. The MOST subsystem is staging; however, it interacts with user-visible device registration and sysfs entries — regressions can show up as missing sysfs nodes or stuck device names.
- Consider adding unit or integration tests that exercise the probe error paths where possible so similar regression windows can be detected earlier in future merges.
Timeline and disclosure notes
- The patch was submitted to the stable kernel mailing list with the visible public patch on 29 October 2025. The commit message describes the non‑standard registration behavior and lists the specific fixes.
- The CVE identifier CVE‑2025‑68290 was published and indexed in mid‑December 2025 across NVD, OSV, and multiple distro trackers as maintainers cataloged the upstream fix and rolled out backports. Distribution trackers (Debian, Ubuntu, SUSE) reflect patched package versions or mitigation guidance following the upstream commit.
Strengths of the response and remaining risks
- Strengths: The fix is small, targeted, and straightforward — it corrects ownership semantics in a focused probe path without a broad subsystem rewrite. That reduces regression risk and makes backporting practical for long‑term support kernels. The change also explicitly balances device references, a robust approach to avoid future double-free regressions in the same code paths.
- Remaining risks:
- Because the flaw is a memory‑corruption class, theoretical exploitation vectors remain attractive to skilled attackers who have local access or can cause a vulnerable probe to run. Even though no public exploit is recorded, defenders should treat the class seriously.
- Systems with custom kernels, niche devices, or slow patch cycles (embedded appliances, industrial systems) may remain exposed; maintainers must prioritize backports for any deployed kernel tree in production. Distribution vendors have started releases, but administrators must verify that their installed kernel packages include the fix.
Quick checklist for IT teams
- Verify whether your systems load the MOST USB driver or have drivers/most compiled in.
- Check your vendor’s kernel advisory and install the provided kernel update (or rebuild with the upstream stable patch).
- If you cannot patch immediately, avoid connecting untrusted MOST devices and consider blacklisting the module.
- Test patched kernels in a staging environment before mass rollout.
- Monitor for kernel oopses referring to drivers/most and treat them as priority incidents.
Conclusion
CVE‑2025‑68290 is a classic example of how subtle ownership and cleanup semantics can lead to memory‑corruption faults in kernel drivers. The maintainers produced a small, effective patch that removes duplicate frees by simplifying probe failure logic and balancing put_device/deregister sequences. Distributors have begun rolling out fixes and backports; administrators should prioritize applying those kernel updates or using the recommended mitigations until systems are patched. While there are no public reports of active exploitation at the time of writing, the underlying bug class justifies a cautious, proactive patching posture.
Source: MSRC
Security Update Guide - Microsoft Security Response Center