CVE-2026-68410: Linux Libertas USB Leak, Not Windows

The National Vulnerability Database published the record on August 10, 2026, using the Linux kernel project’s description and fixed-commit references. The kernel’s own data identifies fixed releases in the maintained branches: Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and upstream 7.2-rc4. Administrators should take those version numbers seriously rather than treating the CVE label alone as a measure of severity: NVD has not assigned a CVSS score, CWE classification, or NIST impact assessment.

The practical conclusion is modest but clear. Update the Linux kernel through the normal distribution channel if a Libertas USB device is in service. Do not elevate this into an emergency incident for Windows fleets, and do not assume that any arbitrary newer-looking vendor kernel contains the correction without checking its changelog or backport record.

A firmware object was retained after a successful load​

The defect is in

, inside the asynchronous

callback. That callback receives a firmware image after the kernel firmware loader completes a request. In the affected one-stage path, it passes the image to

and returns without calling

.

That omission leaves the firmware image allocated after it has done its job. The corrected code adds the missing

call immediately after

returns. This is a conventional resource-lifetime repair: the driver stops retaining a firmware object once the download operation is complete.

The scope is narrower than the generic wording “Linux kernel memory leak” suggests. The vulnerable route requires the Libertas driver to take its single-stage asynchronous firmware path, specifically in the USB firmware-download handling described by the CVE. The same source file already releases objects on its two-stage path: after the main firmware callback runs, it releases both the stored helper firmware and the main firmware. The one-stage success case was the outstanding ownership mismatch.

That code-level distinction changes the operational picture. This is not a leak caused by normal Wi‑Fi traffic, roaming, scan requests, or every use of a Marvell-branded adapter. It occurs during firmware loading for the affected USB driver path. For a device that remains attached and initialized for a long time, the immediate memory impact is likely limited to the firmware object retained during that load. The concern becomes more relevant where the hardware is repeatedly attached, detached, reset, or otherwise causes the driver’s firmware-load sequence to recur.

The CVE number should not be mistaken for a demonstrated exploit​

NVD currently lists no CVSS v2, v3, or v4 score for CVE-2026-68410. More importantly, the public description identifies a memory leak but does not describe out-of-bounds access, use-after-free, information disclosure, privilege escalation, denial of service, or a proof of exploitation.

That does not mean an assigned Linux CVE should be ignored. The kernel project explicitly says its CVE team assigns identifiers cautiously because, at kernel level, the security relevance of a bug fix is often unclear when the fix is made. In other words, a CVE can accurately identify a kernel flaw while still offering very little evidence that the issue is exploitable in a real deployment.

For this record, the evidence supports treating it as a maintenance and reliability correction, not an urgent remote-compromise advisory. A security team should track it under normal kernel patch management, while a platform team responsible for old wireless peripherals should verify whether the Libertas USB module and relevant hardware are actually present. There is no basis in the published record for emergency credential resets, workstation isolation, or a broad Windows endpoint response.

The NVD record also carries a meaningful limitation that should not be buried: the patch author reported that the issue was detected by an experimental memory-management analysis tool, manually confirmed in the then-current wireless tree, and compiled with an x86_64

build without new warnings. But the author did not have compatible Libertas USB hardware, so the corrected firmware-download path was not runtime-tested.

That is a real validation gap, though it does not make the fix speculative. The ownership error is visible in the callback logic, and the repair aligns the one-stage path with the release discipline already used elsewhere in the file. Still, operators maintaining the relevant legacy hardware should prefer a distribution-tested kernel update over manually cherry-picking the one-line change into a custom production build.

Fixed versions are clearer than the affected-version field​

The kernel.org data imported by NVD says the issue is fixed in Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc4. Those are the meaningful remediation landmarks for organizations following those branches.

The same record’s affected-version metadata is less intuitive. It describes Linux 3.13 as affected while also tracking the vulnerable source history from a specific Git commit through separate stable-tree fix commits. That presentation does not establish that every distribution kernel labeled “3.13 or newer” carries identical code, because enterprise distributions commonly backport individual fixes without changing the kernel’s headline version in the way upstream does.

For patch verification, use the distribution’s kernel advisory and build number first. A system reporting an older upstream-style version can be fixed if its vendor has backported the patch; conversely, a custom kernel based on a vulnerable tree may remain exposed even if its local package naming does not resemble upstream’s release sequence. The CVE record offers the five stable Git references for precisely this reason: kernel lineage, not branding, determines whether the code is present.

The record’s original-fix marker is Linux 7.2-rc4, while the listed stable releases show the change was also backported into multiple maintained lines. That reduces the pressure to run a release candidate merely to obtain the fix. Production systems should stay with their supported distribution kernel and move to the vendor build incorporating the appropriate stable update.

WSL systems need a narrower check than Linux servers​

For Windows administrators, the relevant exception is Windows Subsystem for Linux. WSL 2 runs a real Linux kernel in a lightweight virtual machine, so a Linux-kernel CVE can matter inside a WSL environment even though it does not affect the Windows kernel itself.

Even there, CVE-2026-68410 requires more than simply having WSL enabled. The WSL environment would need an affected Linux kernel, the Libertas driver available in that kernel configuration, compatible Libertas USB hardware made available to the Linux guest, and use of the affected firmware-loading path. Most WSL installations will fail one or more of those conditions.

USB devices are not automatically equivalent to native devices inside WSL. Organizations using USB pass-through for lab equipment, embedded development, hardware validation, or legacy Wi‑Fi adapters should inventory the device and confirm its driver binding from the Linux side. A useful first check is whether the Libertas modules are loaded or available, followed by the running kernel release and the distribution’s security advisory status.

For a conventional Windows workstation using built-in Wi‑Fi, a current Intel, Qualcomm, Realtek, MediaTek, Broadcom, or modern USB adapter, this CVE has no direct operational consequence. The Libertas driver is an old Marvell-oriented Linux driver, and the vulnerable path is narrower still: USB firmware download for compatible hardware.

What administrators should do​

The response should be proportionate to the affected hardware and deployment model:

• Linux administrators with Libertas USB hardware should install the next supported distribution kernel containing the relevant stable backport, then reboot or otherwise transition to that kernel under their normal maintenance procedure.
• Teams running custom kernels should compare their source tree against the five kernel.org fix commits or apply the correction as part of a tested kernel update, rather than relying on NVD’s broad affected-version wording.
• WSL administrators should verify whether compatible Libertas USB devices are actually passed through to Linux before spending incident-response time on the CVE.
• Windows endpoint teams without Linux or WSL USB pass-through in scope can record the CVE as not applicable to the Windows host operating system.

CVE-2026-68410 is worth patching where its conditions exist, but the record does not support calling it a broad Wi‑Fi security emergency. Its concrete consequence is simpler: on affected Libertas USB systems, the next supported kernel update closes a firmware-object leak that should have been released after initialization.