Bug 2513353 (CVE-2026-68294)

Summary: CVE-2026-68294 kernel: net: qrtr: restrict socket creation to the initial network namespace
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's QRTR (Qualcomm IPC Router) networking component. An unprivileged local attacker can create a QRTR socket in a separate network namespace. Due to improper handling of global state variables, this allows the attacker to send datagrams and control-plane messages to QRTR sockets in other network namespaces. This bypasses network namespace isolation, enabling unauthorized communication and potential information disclosure between isolated network environments.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-10 12:32:38 UTC
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).

Comment 5 Jon Orris 2026-09-15 00:24:34 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:67469 https://access.redhat.com/errata/RHSA-2026:67469

Comment 6 Jon Orris 2026-09-15 06:28:19 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:67470 https://access.redhat.com/errata/RHSA-2026:67470

Comment 7 Jon Orris 2026-09-17 05:45:23 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:68507 https://access.redhat.com/errata/RHSA-2026:68507