CVE-2026-68294: Linux Fix Blocks QRTR Cross-Namespace Traffic

The NVD published the record on August 10, 2026, based on the kernel.org disclosure and stable-tree fixes. LWN also lists the underlying change, authored by Aldo Ariel Panzardo, among code merged for Linux 7.2-rc5. The fix is deliberately narrow: the kernel now permits QRTR socket creation only from

, the original network namespace created at boot.

For Windows administrators, this is chiefly a WSL 2 and Linux fleet-management issue rather than a Windows kernel vulnerability. Microsoft’s WSL documentation says WSL 2 runs a real Linux kernel built from stable Linux sources and serviced separately from the Windows OS image. Whether a particular WSL kernel even exposes QRTR is a configuration question, but organizations using custom WSL kernels, ARM development images, embedded Linux guests, or container hosts should treat this as a namespace-isolation fix and check their actual kernel package rather than assuming that an ordinary Windows cumulative update covers it.

QRTR’s state was global, while socket access was namespaced​

QRTR—short for Qualcomm IPC Router—is a Linux transport used to communicate with hardware endpoints such as modems and remote processors. It is particularly relevant on Qualcomm-based systems, where software components can use it to discover and talk to services running beyond the main application processor.

The vulnerability arose because QRTR’s local identity and port registry were not per-network-namespace objects. The kernel maintained a single

, always representing node ID 1, and a single global

xarray. QRTR’s lookup and local delivery paths used that shared state without verifying that sender and receiver belonged to the same network namespace.

Linux network namespaces are intended to segregate networking resources. They underpin many containers and can also be created by an unprivileged user in configurations that permit user namespaces. In a vulnerable kernel, a process could create a new user namespace and a new network namespace, open an

socket there, then send QRTR datagrams to a QRTR socket held elsewhere.

The receiving endpoint would see the traffic as originating from local node ID 1—the same identity a legitimate local QRTR client uses. This was more than a case of one namespace seeing an unexpected packet: the global node identity removed the distinction the receiving service would need to reject it as cross-namespace traffic.

The disclosed example includes

, a control-plane message used for service registration and discovery. The advisory does not claim remote code execution, privilege escalation to root, or a route from a container directly into Windows. Its established impact is the loss of a network-namespace boundary for QRTR traffic.

The patch removes an unsupported use case instead of virtualizing QRTR​

The repair does not attempt to make QRTR namespace-aware. Instead, it rejects QRTR socket creation outside the initial network namespace, bringing the socket family in line with other Linux networking interfaces that have no meaningful per-namespace model.

That choice matters operationally. QRTR talks to global hardware endpoints; a modem or remote processor is not duplicated merely because a process enters a new network namespace. Keeping QRTR’s only supported socket context in

matches how its in-kernel name service already behaved, according to the kernel advisory.

It also makes the compatibility tradeoff clear. Software that expected to use

from inside a container, sandbox, or manually created network namespace will stop working after the fix. But such software was depending on behavior the subsystem could not isolate correctly. Maintaining that access would have meant retaining a cross-namespace messaging channel to globally addressed hardware services.

The code path affected is

, and the vulnerability traces back to the QRTR implementation introduced in Linux 4.7. The age of the code is important: this is not confined to a recent regression or a single bleeding-edge release. Older long-term-supported branches can be affected when they contain QRTR and have not received the backport.

Fixed kernel versions are already listed, but package names will vary​

The NVD record identifies fixed upstream release points in five maintained lines:

• Linux 6.6.148 is listed as the fixed point for the 6.6 stable branch.
• Linux 6.12.101 is listed as the fixed point for the 6.12 stable branch.
• Linux 6.18.42 is listed as the fixed point for the 6.18 stable branch.
• Linux 7.1.6 is listed as the fixed point for the 7.1 stable branch.
• Linux 7.2-rc5 contains the original upstream fix.

Those numbers are upstream kernel versions, not a guarantee that a distribution package bearing a superficially older or newer vendor version is exposed. Enterprise Linux vendors, Ubuntu, Debian, SUSE, Android-derived platforms, appliance makers, and cloud-image publishers often backport individual patches while retaining their own versioning and ABI labels.

Admins should therefore use the vendor’s package changelog, security tracker, or source package record to identify the backport. The most reliable technical test is whether the installed source contains the namespace restriction in QRTR socket creation—not whether a scanner recognizes only the upstream version number.

The NVD entry currently has no CVSS v3 or CVSS v4 score and no CWE classification. That means vulnerability-management platforms that rely on NVD enrichment may initially show the CVE without a severity rating, or may prioritize it inconsistently. A missing NVD score is not evidence that the bug is harmless; it means NIST has not completed that assessment as of August 11.

WSL 2 users should verify the kernel, not Windows build number​

WSL 1 is not in scope because it does not run a full Linux kernel. WSL 2 is more complicated: it uses a managed Linux virtual machine and Microsoft-built kernel, while custom kernels can be selected through

. Microsoft documents

and

as ways to inspect the installed kernel and WSL components, and

as the normal update path.

The CVE should not be inflated into a generic “WSL escape.” The advisory describes communication across Linux network namespaces within the same kernel. It does not document a way to cross WSL’s Hyper-V isolation into the Windows host, and it does not establish that Microsoft’s standard WSL kernel builds QRTR support at all.

Still, the architecture produces a concrete administrative consequence: a custom WSL kernel can miss a security backport even when the Windows host and the Store-delivered WSL application are current. Developers using a custom kernel for USB, device, networking, or virtualization features should inspect it directly with

, then compare its QRTR patch status with the vendor’s source or changelog.

For Microsoft-managed WSL installations, running

is the appropriate servicing action once Microsoft ships a kernel containing the backport. For custom WSL kernels and conventional Linux hosts, update through the distribution or image vendor’s supported channel, then restart the affected VM, host, or WSL instance so the new kernel is actually running. A

followed by relaunching the distribution is the straightforward way to ensure WSL does not retain the prior kernel session.

Container hosts need to review QRTR exposure​

The trigger described by kernel.org does not require a privileged container in the usual sense. An unprivileged process needs the ability to create a user namespace and a network namespace, then open an

socket. Whether that is feasible depends on host policy, container runtime settings, user-namespace controls, seccomp profiles, and whether QRTR is built into or loaded by the running kernel.

That narrows the immediate concern. General-purpose servers without Qualcomm hardware, without the QRTR module, or with policies that prevent the relevant namespace creation may have little practical exposure. But security boundaries should be assessed by the kernel interfaces available to a workload, not by the assumption that a workload has no reason to contact a modem.

The patch closes the gap at the correct boundary: QRTR sockets in non-initial network namespaces will no longer exist to exchange traffic with the global QRTR registry. Until patched kernels are deployed, hosts that expose QRTR and allow untrusted code to create network namespaces should regard their namespace isolation as incomplete.