CVE-2026-52947: Linux Kernel QRTR Race Condition and Use-After-Free Vulnerability

Technical summary

The vulnerability resides in qrtr_port_remove() in the QRTR subsystem. The function calls __sock_put() to decrement the socket reference count before invoking xa_erase() to remove the port from the qrtr_ports XArray and before synchronize_rcu() completes. This violates RCU (Read-Copy-Update) synchronization semantics. Concurrent RCU readers—such as qrtr_reset_ports() or qrtr_port_lookup()—can retrieve a pointer to the socket from the XArray and attempt sock_hold(), which triggers refcount_warn_saturate() when the reference count has already reached zero. The fix defers __sock_put() until after both xa_erase() and synchronize_rcu() complete, restoring proper RCU update ordering and preventing the race window.

Business impact

Exploitation could allow a local, unprivileged user to corrupt kernel memory, trigger denial of service, or potentially escalate privileges. QRTR is used in systems requiring inter-process communication over sockets—primarily mobile and edge devices, automotive platforms, and IoT systems running Linux. Attack success depends on precise timing but has been reproducibly demonstrated via syzkaller, indicating practical exploitability. Systems with QRTR enabled and accessible to local users face heightened risk.

Affected systems

All Linux kernel versions with the QRTR module compiled in. The vulnerability affects the net/qrtr/af_qrtr.c subsystem. Affected users include those running kernels with CONFIG_QRTR=y or CONFIG_QRTR=m. Distributions shipping QRTR support in default or commonly-used kernel configurations are at risk.

Exploitability

Exploitability is rated HIGH (CVSS 7.8). The vulnerability requires local access and a low privilege level (unprivileged user), but no special interaction is needed. The race condition was reliably triggered during fuzzing, demonstrating that exploitation is feasible without requiring specialized timing techniques or kernel internals knowledge. The attack surface is broad: any local user capable of triggering QRTR port operations can attempt to race the vulnerable code path.

Remediation

Apply the kernel patch that defers __sock_put() until after xa_erase() and synchronize_rcu() complete. This repositioning closes the RCU race window while preserving the refcount semantics required by the socket's calling context. Verify against the upstream kernel commit or your distribution's security advisory for the exact patch version. No userspace workarounds are available; kernel update is required.

Patch guidance

Consult your Linux distribution's security advisory for the patched kernel version. Upstream, the fix has been merged into the kernel mainline. Test the patched kernel in a staging environment to confirm QRTR functionality and stability before deploying to production. If you have custom kernel builds, ensure CONFIG_QRTR is patched or disabled if not required.

Detection guidance

Monitor kernel logs for 'refcount_t: saturated; leaking memory' warnings in conjunction with QRTR stack traces (qrtr_reset_ports, qrtr_port_lookup, qrtr_port_remove). Use kernel address sanitizers (KASAN) or memory tagging if available to detect use-after-free conditions. System calls related to socket binding on QRTR interfaces (e.g., qrtr_bind) combined with concurrent port removal may indicate exploitation attempts. Audit systems with QRTR enabled to prioritize patching.

Why prioritize this

This vulnerability should be prioritized HIGH because it affects local privilege escalation and kernel stability, carries a CVSS 7.8 score, has been confirmed reproducible via fuzzing, and affects all systems with QRTR enabled. Although it requires local access, the low barrier to user-level exploitation and the potential for memory corruption make it a critical patching target.

Risk score, explained

CVSS 3.1 score of 7.8 (HIGH severity) reflects Attack Vector: Local, Attack Complexity: Low, Privileges Required: Low, User Interaction: None, and impacts on Confidentiality, Integrity, and Availability (all High). The score appropriately captures the kernel-level nature of the flaw and the ease of triggering the race condition without special privileges or user interaction.

Frequently asked questions