CVE-2026-46003

What it actually does

CVE-2026-46003 is a local denial-of-service vulnerability in the Linux kernel Qualcomm IPC Router (QRTR) nameserver component. The QRTR nameserver did not enforce an upper bound on the number of registered nodes it would track. A local, low-privileged attacker able to interact with the QRTR subsystem could repeatedly register arbitrary or random nodes, causing unbounded kernel memory growth and eventual memory exhaustion. The practical impact is loss of system availability through kernel memory pressure, out-of-memory conditions, service instability, or system crash. Confidentiality and integrity are not directly impacted.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, which may interrupt workloads, embedded services, mobile/IoT platforms, edge devices, or infrastructure that depends on QRTR-enabled kernels. Because exploitation requires local access and there is no known public exploit or CISA KEV listing, broad internet-scale risk is lower than for remote vulnerabilities; however, multi-user systems, containerized environments with access to relevant kernel interfaces, and devices running untrusted local code should treat this as a meaningful availability risk.

How an attack unfolds

An attacker first obtains local execution capability on a system running an affected Linux kernel. They then interact with the QRTR nameserver functionality and repeatedly register many distinct, randomly generated node identifiers. Because vulnerable kernels do not cap the number of nodes maintained by the nameserver, each registration consumes additional kernel memory. Over time, the uncontrolled growth drives memory pressure until the system degrades, kills processes, fails services, or crashes. The vulnerability is remediated by limiting the total number of QRTR nameserver nodes to 64, preventing an attacker from exhausting memory through unbounded node registration.

How to fix it

Apply the Linux kernel update that includes the upstream fix for QRTR nameserver node limiting. The fix limits the total number of QRTR nameserver nodes to 64, preventing unbounded memory consumption. Where distribution-specific packages are used, upgrade to the vendor kernel version that backports this patch and reboot into the fixed kernel. If immediate patching is not possible, reduce exposure by disabling or removing QRTR support where it is not required, limiting local shell access, restricting execution of untrusted code, and using kernel hardening and resource-control mechanisms where applicable. Validate that systems are actually running the updated kernel after package installation, as kernel fixes generally require a reboot.

How to confirm the fix worked

Confirm the running kernel includes the QRTR nameserver node-limit patch from the Linux vendor or upstream stable branch. Check the active kernel version with standard system tooling such as uname -a and compare it against the vendor advisory or package changelog for this vulnerability. Confirm the system has been rebooted after the kernel update. Where source or symbols are available, verify that the QRTR nameserver implementation enforces a maximum node count, expected to be 64. For exposure assessment, identify systems with QRTR enabled or loaded, such as by checking for qrtr-related kernel modules, sockets, logs, or configuration. Avoid destructive validation in production; if testing is needed, perform it in an isolated lab by attempting excessive QRTR node registration and confirming the fixed kernel rejects additional nodes rather than allowing unbounded memory growth.

Typical attack path

1. Obtain local code execution or shell access on an affected Linux system.
2. Confirm that the QRTR subsystem is available and accessible from the local context.
3. Create or use a client capable of communicating with the QRTR nameserver.
4. Repeatedly register large numbers of random or unique QRTR nodes.
5. Consume increasing amounts of kernel memory due to unbounded nameserver node tracking.
6. Trigger system instability, out-of-memory behavior, service failure, or crash.

How to detect it

To determine whether exploitation has already occurred, review host telemetry for unexplained memory exhaustion or availability failures correlated with local processes interacting with QRTR. Useful sources include kernel logs, system journal entries, auditd events, endpoint detection telemetry, process execution logs, container runtime logs, and monitoring data for memory pressure. Look for out-of-memory killer events, rapid kernel memory growth, service crashes, or reboots without another clear cause. Investigate local processes that opened QRTR sockets, loaded qrtr-related modules, or executed unusual custom binaries before memory exhaustion. On systems with audit policies capable of tracing socket families or relevant device interactions, search for bursts of QRTR-related activity from the same user or process. There are no public reports of exploitation, no named threat actors, and no KEV listing for this vulnerability in the provided intelligence, so detection should focus on behavioral evidence rather than known attacker infrastructure.

• Out of memory: Killed process
• oom-killer
• Memory cgroup out of memory
• Kernel panic - not syncing: Out of memory
• qrtr
• qrtr_ns
• QRTR
• AF_QIPCRTR
• /proc/net/qrtr
• NETLINK_QRTR

What your security team should do

• Prioritize patching systems where untrusted users, containers, sandboxed workloads, or third-party applications can execute local code.
• Inventory Linux systems that include or enable QRTR support, especially Qualcomm-based, embedded, mobile, edge, or specialized communication platforms.
• Upgrade to a vendor kernel containing the QRTR nameserver node-limit fix and reboot systems into the fixed kernel.
• If patching is delayed, restrict local access and remove or disable QRTR functionality where operationally unnecessary.
• Monitor for abnormal kernel memory growth, out-of-memory killer activity, repeated QRTR-related errors, or sudden local-service instability.
• Review container and workload isolation policies to ensure untrusted workloads cannot unnecessarily access kernel interfaces related to QRTR.
• Track Linux distribution advisories for exact fixed kernel package versions because fixed_versions were not provided in the input.
• Treat exploitation likelihood as currently low based on low EPSS, no known exploit maturity, and no KEV listing, but maintain remediation because the impact is high availability loss.