CVE-2026-52947

What it actually does

This is a race condition in the Linux kernel QRTR networking code involving socket reference counting and RCU-protected lookups. In qrtr_port_remove(), the socket reference count can be decremented before the socket is removed from the qrtr_ports XArray and before the RCU grace period completes. A concurrent reader can then retrieve a stale socket pointer and attempt to increment a reference count that has already reached zero, producing refcount saturation and creating a potential use-after-free condition. Depending on kernel configuration, timing, and memory reuse, the practical result may range from kernel warnings and memory leaks to denial of service or, in a worst case, kernel memory corruption.

Why it matters to the business

Systems running affected Linux kernels with QRTR support may be exposed to local stability and availability risk. Successful triggering could crash or destabilize a host, interrupt workloads, or require emergency reboots. No public exploitation or CISA KEV listing is indicated, and the EPSS score is very low, so this should generally be treated as a kernel maintenance and hardening priority rather than an active mass-exploitation emergency. However, because kernel use-after-free flaws can become more serious if exploitability improves, organizations with exposed multi-user Linux systems, container hosts, mobile/embedded Linux platforms, or Qualcomm/QRTR-dependent environments should prioritize kernel updates during the next appropriate patch cycle.

How an attack unfolds

An attacker needs the ability to exercise the affected QRTR kernel code path, typically from a local context or from software able to create and manipulate QRTR sockets if the QRTR module or feature is available. The attacker attempts to create concurrent operations that remove a QRTR port while another QRTR path, such as a reset or lookup operation, reads the same port through the RCU-protected XArray. If the race is won, the reader can obtain a pointer to a socket whose reference count has already been dropped to zero and then call sock_hold() on that invalid or dying object. This can trigger refcount saturation warnings, leak memory, or potentially produce a use-after-free if the object is reclaimed and reused. There is no stated public exploit maturity, and the issue was identified through syzkaller fuzzing, so exploitation should be considered timing-sensitive and likely reliability-dependent at this time.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the QRTR reference-counting and RCU ordering issue. The corrected behavior removes the port from the XArray, waits for the RCU grace period, and only then decrements the socket reference count. Because no affected product list or exact fixed package versions were provided, use vendor advisories for the specific Linux distribution, appliance, embedded platform, Android/vendor kernel, or cloud image in use. Where immediate patching is not possible, reduce exposure by disabling or preventing loading of the qrtr module if it is not required, restricting untrusted local shell access, limiting container privileges, and applying kernel hardening and least-privilege controls that reduce the ability of untrusted workloads to interact with uncommon address families or kernel modules. Mitigations should be validated carefully before disabling QRTR on systems that rely on Qualcomm IPC Router functionality or related modem/embedded communication components.

How to confirm the fix worked

Confirm that the running kernel package or vendor kernel build contains the fix for the QRTR qrtr_port_remove() ordering issue. Validate the active kernel with uname -a and package manager queries, then compare against the vendor security advisory or changelog for this vulnerability. Confirm whether QRTR is present or loaded by checking kernel configuration, loaded modules, and module availability, such as lsmod, modinfo qrtr, and /proc/modules. After patching, reboot into the fixed kernel and verify the old kernel is not still running. Review kernel logs before and after remediation for QRTR-related refcount warnings, use-after-free reports, KASAN findings, or unexplained kernel oops/panic events. If QRTR is not needed and has been disabled as a mitigation, validate that the qrtr module cannot be loaded and that required system functionality remains intact.

Typical attack path

1. Identify a Linux system running a kernel build that includes the affected QRTR networking code or has the qrtr module available.
2. Obtain local code execution or another execution context capable of interacting with QRTR sockets or triggering QRTR namespace/port operations.
3. Create repeated QRTR socket bind, lookup, reset, and teardown activity to increase contention around qrtr_port_remove() and concurrent RCU readers.
4. Race port removal against QRTR lookup/reset paths so a reader obtains a socket pointer after its reference count has already been decremented to zero.
5. Trigger kernel refcount saturation, memory leakage, instability, or a potential use-after-free condition.
6. Use the resulting condition to cause denial of service or, if a reliable exploit is developed, attempt further kernel-level impact.

How to detect it

Look for evidence in kernel logs and crash artifacts rather than network telemetry, because this flaw is a local kernel race and no specific remote exploit signature is available. Review dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, vmcore data, KASAN reports, and kernel oops/panic records for QRTR-related warnings. Strong signals include refcount saturation messages, stack traces involving qrtr_reset_ports(), qrtr_port_lookup(), qrtr_port_remove(), __qrtr_bind(), qrtr_bind(), qrtr_ns_init(), or qrtr_proto_init(), and messages showing the qrtr module loaded near the time of instability. Correlate these events with local process activity, container workload launches, fuzzing tools, unexplained module loading, repeated socket creation, or user activity immediately before the crash. Because the issue was reported from syzkaller-style fuzzing and there is no known public exploit maturity, isolated warnings may indicate testing, instability, or benign triggering; repeated occurrences on production systems should be investigated as possible attempted exploitation or unsafe workload behavior.

• refcount_t: saturated; leaking memory.
• refcount_warn_saturate
• WARNING: CPU:
• Modules linked in: qrtr
• qrtr_port_remove
• qrtr_reset_ports
• qrtr_port_lookup
• __qrtr_bind
• qrtr_bind
• qrtr_ns_init
• qrtr_proto_init
• net/qrtr/af_qrtr.c
• net/qrtr/ns.c
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG at lib/refcount.c
• kernel panic
• Oops:

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and kernel-derived platforms where QRTR support is enabled, built in, or loadable as a module.
• Prioritize patching multi-user systems, container hosts, systems running untrusted workloads, and Qualcomm/QRTR-dependent platforms once vendor-fixed kernels are available.
• Monitor distribution and vendor kernel advisories for the exact fixed kernel versions because no fixed versions were provided in the input.
• If QRTR is not operationally required, consider disabling or blocking the qrtr module as a temporary mitigation after compatibility testing.
• Restrict untrusted local access and reduce container privileges, especially access patterns that allow broad kernel attack-surface interaction.
• Search kernel logs for refcount saturation, QRTR stack traces, KASAN reports, kernel oops messages, or repeated QRTR module initialization/bind activity.
• Treat any QRTR-related kernel warning followed by instability or panic as potentially security-relevant and preserve logs, vmcore data, and kernel versions for investigation.
• Track EPSS and exploit maturity changes; current exploitation likelihood appears low, but kernel use-after-free issues can become more urgent if a reliable exploit is released.