CVE-2026-68294

In the Linux kernel, the following vulnerability has been resolved:

net: qrtr: restrict socket creation to the initial network namespace

QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in.

As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide.

QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).

Weakness

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

Affected Software

Potential Mitigations

• Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
• Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
• For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
• For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
• One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/665.html

References

• https://git.kernel.org/stable/c/2d22b94a154ccb9755dddfff802fe3e2b1adbab5
• https://git.kernel.org/stable/c/3b536db8fb32da9e9c62f2bb45e2e319331f0426
• https://git.kernel.org/stable/c/4b95e1f0d6e6342c427cb341ee18a894b146b789
• https://git.kernel.org/stable/c/659b9b4f194bb56b9903cc95e786ef1d438baa7d
• https://git.kernel.org/stable/c/7814f6a3415cad38aa8d6dfc573df778260d66aa
• https://git.kernel.org/stable/c/8150c48fb978e01689f94ed80148f8a7499ae571
• https://git.kernel.org/stable/c/8d351fe0654a20c9f95a61b05d24ebe6d4be3fbb
• https://git.kernel.org/stable/c/f488116df769bdaf89c93371350e49e12133e70f