CVE-2026-43491

What it actually does

CVE-2026-43491 is a local denial-of-service flaw in the Linux kernel Qualcomm IPC Router (QRTR) name service handling. The vulnerable code does not enforce a bound on the number of server registrations that can be added per QRTR node. A local, low-privileged actor able to send QRTR NEW_SERVER messages can repeatedly register servers until kernel memory is exhausted, causing severe availability degradation or system instability. The upstream fix caps server registrations at 256 per node, allows replacement of existing ports, and rate-limits related error logging to reduce secondary log-flooding impact.

Why it matters to the business

Successful exploitation can cause affected Linux systems to become unstable, unresponsive, or crash due to memory exhaustion. The primary business risk is service interruption on systems using the QRTR subsystem, especially platforms that expose or rely on Qualcomm-related IPC functionality. The vulnerability is not known to be exploited in the wild, is not listed in CISA KEV, has low EPSS, and requires local privileges, so it is generally a lower-priority patch than remotely exploitable kernel flaws; however, it can still be important on multi-user systems, shared compute platforms, embedded devices, and environments where local code execution by untrusted users or workloads is possible.

How an attack unfolds

An attacker first obtains the ability to run code locally as an unprivileged user or within a workload that can interact with the kernel QRTR name service. They then send a large number of QRTR NEW_SERVER messages for a node, using new ports so the registrations are added rather than replacing existing entries. On vulnerable kernels, the name service continues allocating memory for these registrations without an effective per-node limit. As memory pressure increases, the host may experience degraded performance, out-of-memory conditions, service failures, or a kernel crash. The patched behavior stops the attack by refusing registrations once the per-node maximum is reached and by rate-limiting associated error messages.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the QRTR name service fix limiting server registrations to 256 per node and rate-limiting failure-path error messages. Because fixed versions vary by distribution and kernel branch, use the security advisory from the operating system or appliance vendor and confirm that the specific kernel package includes the backported fix for CVE-2026-43491. If immediate patching is not possible, reduce exposure by limiting local shell/container access to trusted users, disabling or removing QRTR-related functionality where it is not required, applying workload isolation and resource controls such as cgroups, and monitoring for abnormal memory growth or QRTR-related log activity. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated to a vendor build containing the fix. Validate with `uname -a` and distribution package tools such as `rpm -q --changelog kernel`, `dpkg -l linux-image-*`, `apt changelog`, or vendor advisory metadata. Where source validation is possible, confirm the QRTR name service code enforces a maximum of 256 server registrations per node and rate-limits the relevant failure logging path in `qrtr_ns_worker()`. Operationally, verify that systems have rebooted into the fixed kernel and that QRTR registration flooding no longer causes unbounded memory growth. Exposure can also be assessed by checking whether QRTR support is present in the running kernel and whether local untrusted users or workloads can interact with it.

Typical attack path

1. Gain local code execution or access to a local workload/user context on an affected Linux system.
2. Determine that the QRTR subsystem/name service is present and usable.
3. Generate repeated QRTR NEW_SERVER registration messages for the same node using many distinct ports.
4. Force the kernel to allocate unbounded server-registration state for that node.
5. Continue the flood until memory pressure causes service degradation, out-of-memory behavior, or system instability.
6. Optionally repeat after reboot or service recovery to sustain denial of service.

How to detect it

Look for signs of local denial-of-service activity rather than remote network exploitation. Useful sources include kernel logs (`dmesg`, `/var/log/kern.log`, `/var/log/messages`, journald), audit logs, endpoint process telemetry, container runtime logs, and memory/OOM monitoring. Search for QRTR or Qualcomm IPC Router name-service errors occurring in bursts, followed by memory pressure, OOM-killer events, service crashes, or system reboots. Correlate the timing with local user sessions, recently launched binaries, scheduled jobs, or containers. Because public exploit maturity is currently reported as none and the issue is not in CISA KEV, detections should focus on anomalous QRTR activity and resource exhaustion patterns rather than known malware signatures. If threat hunting identifies repeated QRTR-related failures, determine which process opened QRTR sockets or triggered the activity using audit/eBPF/EDR telemetry where available.

• qrtr
• QRTR
• qmi
• qmi_wwan
• qrtr_ns_worker
• NEW_SERVER
• Out of memory
• oom-killer
• invoked oom-killer
• Memory allocation failure
• Killed process
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k

What your security team should do

• Inventory Linux systems, especially embedded, mobile, edge, Qualcomm-based, shared, or multi-tenant systems, to identify kernels that may include the vulnerable QRTR name service code.
• Prioritize patching where untrusted local users, containers, jobs, or applications can run code on the host, because exploitation requires local access but can cause high availability impact.
• Deploy vendor kernel updates that include the fix, then reboot systems into the updated kernel and verify the running version.
• For systems that cannot be patched quickly, restrict local access, tighten container and workload isolation, and apply memory/resource limits to reduce the blast radius of local denial-of-service attempts.
• Monitor kernel logs and host telemetry for QRTR name service errors, sudden memory exhaustion, OOM-killer activity, and repeated local processes interacting with QRTR sockets.
• Treat exploitation evidence as a sign of local compromise or misuse and investigate the user, process, container, or workload that generated abnormal QRTR traffic.