CVE-2026-46026

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel QRTR nameservice implementation. A local, low-privileged process can repeatedly send QRTR NEW_LOOKUP messages over the same socket because vulnerable kernels do not adequately bound the number of active lookup registrations. Excessive lookup creation can consume kernel-side resources or trigger degraded behavior in the QRTR nameservice path, affecting system availability. The issue is local-only, requires code execution on the host, and does not directly enable confidentiality or integrity compromise.

Why it matters to the business

Successful exploitation can cause affected Linux systems to become unstable, degraded, or unavailable, especially on platforms that rely on QRTR/Qualcomm IPC Router functionality. The practical business risk is service disruption rather than data theft. Because exploitation requires local access and there is no known public exploit maturity, KEV listing, ransomware association, or meaningful EPSS signal at this time, urgency is moderate; however, systems with untrusted local users, container workloads, shared shell access, or embedded/mobile Qualcomm-adjacent components should prioritize remediation.

How an attack unfolds

An attacker first obtains the ability to run code locally on an affected Linux system, such as through a compromised user account, malicious local workload, or untrusted container with sufficient kernel interface access. The attacker opens a QRTR socket and repeatedly sends NEW_LOOKUP messages to the QRTR nameservice. On vulnerable kernels, the nameservice does not enforce a safe upper bound on the number of lookup registrations a client can create, allowing a flood of lookup requests over the same socket. As the kernel processes and tracks these excessive lookups, availability can be impacted through resource exhaustion, kernel subsystem instability, or loss of QRTR nameservice responsiveness. The upstream fix limits the maximum number of lookups to 64 globally, preventing unbounded accumulation.

How to fix it

Upgrade to a Linux kernel version that includes the QRTR nameservice fix limiting the maximum number of lookups to 64. If distribution-specific fixed package versions are not available, apply the relevant vendor kernel update as soon as it is released and verify that the patch for net/qrtr/ns lookup limiting is included. Where immediate patching is not possible, reduce exposure by restricting local code execution, limiting untrusted shell access, hardening container boundaries, disabling or removing unused QRTR-related functionality where operationally safe, and applying least-privilege controls that prevent untrusted workloads from interacting with unnecessary kernel interfaces. Monitor vendor advisories for exact fixed package versions for the deployed distribution and kernel branch.

How to confirm the fix worked

Confirm remediation by checking the running kernel package against the Linux distribution vendor advisory or by verifying that the kernel source/build includes the QRTR nameservice lookup limit fix. Validate that the running kernel is the updated kernel after reboot, not merely that an updated package is installed. Where source verification is possible, confirm the QRTR nameservice implementation enforces a bounded maximum lookup count, with a global maximum of 64 lookups. For exposure validation, determine whether QRTR support is enabled in the kernel and whether untrusted local users or workloads can access the relevant local socket interface. Avoid destructive proof-of-concept testing on production systems; if testing is required, perform it only in an isolated lab and verify that excessive NEW_LOOKUP attempts are rejected or bounded rather than accumulating indefinitely.

Typical attack path

1. Gain local code execution on an affected Linux system.
2. Determine whether QRTR support is present and reachable from the local context.
3. Create or reuse a QRTR socket as a local client.
4. Send a high volume of QRTR NEW_LOOKUP messages over the socket.
5. Exhaust or stress QRTR nameservice lookup handling due to lack of bound checking.
6. Cause service degradation, subsystem instability, or host-level availability impact.

How to detect it

To determine whether exploitation may have occurred, review host telemetry for abnormal local process activity involving QRTR sockets and repeated message sends to the QRTR nameservice. Useful sources include auditd logs, eBPF or syscall tracing telemetry, EDR process/network telemetry, kernel logs, systemd journal entries, OOM killer logs, crash dumps, and performance monitoring around the time of instability. Look for short-lived or unusual local processes creating QRTR sockets and issuing large numbers of sendmsg calls, followed by QRTR errors, kernel soft lockups, high CPU usage in kernel context, memory pressure, service stalls, or host reboots. On containerized systems, correlate the activity to the originating workload or namespace. Because this flaw is a local denial-of-service condition, forensic evidence may be limited and may not contain a clean exploit marker unless detailed syscall or eBPF telemetry was already enabled.

• NEW_LOOKUP
• qrtr
• QRTR
• AF_QIPCRTR
• qrtr-ns
• net/qrtr/ns.c
• sendmsg
• soft lockup
• Out of memory
• oom-killer

What your security team should do

• Prioritize patching affected Linux kernels on multi-user systems, shared compute hosts, container platforms, and devices that rely on QRTR functionality.
• Track vendor-specific kernel advisories and deploy the first fixed kernel available for each supported distribution and branch.
• Inventory systems with QRTR support enabled, especially Qualcomm-adjacent embedded, mobile, IoT, or specialized Linux platforms.
• Restrict local execution paths for untrusted users and workloads until fixed kernels are deployed.
• Review container and sandbox configurations to ensure untrusted workloads cannot unnecessarily access host kernel IPC interfaces.
• Add monitoring for suspicious local processes repeatedly interacting with QRTR or generating high rates of sendmsg activity to QRTR sockets.
• Investigate unexplained host instability, kernel soft lockups, OOM events, or QRTR-related errors on affected kernels.
• Because this issue is not currently KEV-listed and has very low EPSS, sequence remediation after remotely exploitable critical issues, but do not defer on systems where local untrusted code execution is common.