CVE-2026-46038

What it actually does

CVE-2026-46038 is a local denial-of-service flaw in the Linux kernel Qualcomm IPC Router (QRTR) nameservice handling. When a QRTR node sends a BYE control packet, the kernel nameserver is supposed to remove the node from its internal Xarray and free the associated memory. Vulnerable kernels fail to free that node memory after processing the BYE packet, causing a memory leak. A local, low-privileged attacker who can interact with QRTR can repeatedly trigger node teardown events to consume kernel memory over time, potentially leading to memory pressure, service instability, or an out-of-memory condition. The flaw does not provide confidentiality or integrity impact and does not directly grant code execution or privilege escalation.

Why it matters to the business

Systems running affected Linux kernels may become unstable or unavailable if local users or workloads can repeatedly trigger the vulnerable QRTR BYE handling path. The practical business risk is service disruption: degraded performance, failed workloads, process termination by the out-of-memory killer, or host reboot/recovery activity. Because exploitation requires local access and there is no known public exploit maturity or CISA KEV listing, urgency is lower than for remotely exploitable kernel bugs; however, multi-user systems, shared compute platforms, container hosts, mobile/embedded Linux deployments, and environments using Qualcomm/QRTR-related functionality should prioritize kernel updates during the next appropriate maintenance window.

How an attack unfolds

An attacker first obtains local code execution on a system running a vulnerable Linux kernel, such as through an unprivileged shell, compromised local account, container escape-adjacent capability, or malicious local workload with access to QRTR interfaces. The attacker then interacts with the QRTR nameservice in a way that creates or references QRTR nodes and repeatedly causes BYE control packets to be processed. Each BYE event should remove and free the node, but on vulnerable kernels the node memory remains allocated. By repeating this cycle, the attacker gradually increases unreclaimed kernel memory usage. As memory pressure grows, legitimate workloads may slow, allocation failures may occur, the kernel may invoke the out-of-memory killer, and the host may experience service degradation or denial of service.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for QRTR nameservice BYE handling, specifically the change that removes the node from the Xarray and frees node memory in ctrl_cmd_bye() on both success and failure paths. Because no fixed package versions were provided, use vendor advisories for the relevant distribution or appliance to identify the corrected kernel package. After installing the fixed kernel, reboot into the updated kernel; live patching should only be considered sufficient if the vendor explicitly states this specific QRTR fix is covered. Where immediate patching is not possible, reduce exposure by disabling or preventing use of QRTR functionality where operationally safe, unloading unused QRTR-related modules if supported, restricting local shell access, limiting untrusted workloads, and enforcing resource controls on shared systems. Mitigations should be treated as temporary because they may not fully prevent local kernel memory exhaustion.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version is the vendor-fixed version, not merely that an updated package is installed. On Linux systems, compare uname -r against the distribution security advisory and package changelog for the QRTR ctrl_cmd_bye() memory leak fix. If kernel source or debug symbols are available, confirm the QRTR nameservice BYE path removes the node from the Xarray and frees it during both successful and failed BYE processing. Validate exposure by checking whether QRTR support is present or loaded, for example by reviewing loaded modules and kernel configuration for QRTR-related networking support. Operationally, monitor memory behavior after upgrade under representative QRTR activity and confirm there is no progressive unreclaimed kernel memory growth associated with QRTR node teardown activity.

Typical attack path

1. Gain local execution on a Linux system running an affected kernel.
2. Determine that QRTR support is available or loaded on the host.
3. Create or interact with QRTR node state through local QRTR-capable interfaces.
4. Trigger repeated QRTR BYE control handling for nodes that are going down.
5. Cause vulnerable kernel code to retain node memory instead of freeing it.
6. Repeat until kernel memory pressure causes workload failures, OOM kills, instability, or host unavailability.

How to detect it

Retrospective detection should focus on symptoms of local kernel memory exhaustion rather than a reliable exploit fingerprint, because this flaw is a memory leak in kernel QRTR BYE handling and may not produce a distinctive log entry. Review kernel logs, system journal, crash dumps, and monitoring data for unexplained increases in kernel memory usage, slab growth, allocation failures, OOM-killer activity, service restarts, or host reboots. Correlate those events with local user activity, newly introduced workloads, containers, or processes interacting with QRTR/Qualcomm IPC Router interfaces. On systems with auditd, eBPF, or endpoint telemetry, look for processes opening or using QRTR-related sockets or netlink families shortly before memory pressure events. If crash dumps or memory diagnostics are available, inspect for abnormal accumulation of QRTR nameservice node objects or related kernel allocations. Because there are no named threat actors, no KEV listing, and no known exploit maturity in the supplied data, absence of known campaign indicators should not be used to rule out local abuse.

• Out of memory: Killed process
• oom-killer
• page allocation failure
• Memory allocation failure
• invoked oom-killer
• NETLINK_QRTR
• AF_QIPCRTR
• qrtr
• qrtr_ns

What your security team should do

• Inventory Linux systems running kernels with QRTR support, prioritizing shared, multi-user, container-host, embedded, mobile, and Qualcomm-related deployments.
• Track the applicable Linux distribution or vendor advisory and deploy the fixed kernel as soon as it is available for the platform.
• Reboot systems after kernel update and verify the running kernel is the remediated build.
• If patching is delayed, restrict local access and untrusted workloads on exposed systems, and disable unused QRTR functionality where safe.
• Add monitoring for abnormal kernel memory growth, OOM-killer activity, and host instability that could indicate attempted denial-of-service exploitation.
• Review recent incidents involving unexplained memory exhaustion on affected systems for possible QRTR-related triggering, especially where local untrusted code was present.
• Do not treat the absence of public exploit maturity or KEV status as proof of safety; local denial-of-service flaws can still be abused by compromised accounts or malicious workloads.