CVE-2026-46047: Linux Kernel Use-After-Free Vulnerability

CVE-2026-46047 Overview

CVE-2026-46047 is a use-after-free vulnerability in the Linux kernel's Qualcomm IPC Router (QRTR) name service subsystem. The flaw resides in the driver remove() callback path within net/qrtr/ns.c. When the driver is removed, a race window exists between destroy_workqueue() and sock_release(). If a packet arrives during that window, the qrtr_ns_data_ready() callback attempts to queue work on a workqueue that has already been destroyed. The result is dereferencing freed memory inside kernel context. The issue has been resolved across multiple stable kernel branches via upstream commits.

Critical Impact
A use-after-free in kernel networking code can lead to memory corruption, denial of service, or potential privilege escalation on systems using QRTR.

Affected Products

Linux kernel builds that include the QRTR name service (net/qrtr/ns.c)
Distributions and devices using Qualcomm IPC Router, including many Qualcomm-based platforms
Kernel branches prior to the fixes referenced in the upstream stable commits

Discovery Timeline

2026-05-27 - CVE-2026-46047 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-46047

Vulnerability Analysis

The QRTR name service registers a custom sk_data_ready handler, qrtr_ns_data_ready(), that schedules work onto a dedicated workqueue. The work item then processes incoming control packets. During module or driver teardown, the remove path calls destroy_workqueue() before sock_release(). Because the socket remains live between these two calls, the kernel can still deliver packets to it. Each delivered packet triggers qrtr_ns_data_ready(), which queues work onto the now-freed workqueue structure. This dereference of freed memory is a classic use-after-free [CWE-416].

The fix saves the original sk_data_ready callback during qrtr_ns_init() and restores it as the first action of the remove path. After restoration, new packets no longer reach qrtr_ns_data_ready(). The fix also ensures RX threads complete before the workqueue is destroyed, eliminating the residual race.

Root Cause

The root cause is incorrect teardown ordering combined with a missing synchronization barrier. The remove path released resources required by an active callback before detaching that callback from the socket. Concurrent RX threads could still be executing the callback when its backing workqueue was destroyed.

Attack Vector

Exploitation requires the ability to send QRTR packets to the name service socket at the moment the driver is being unloaded or the subsystem torn down. On affected Qualcomm platforms, local components communicating over QRTR could trigger the race. Practical exploitation is constrained by the narrow timing window and the privileges needed to influence driver removal. See the upstream commits (0f313eb, 2e127ce, 7809fea, db3c60e, f96779e) for the exact code paths.

No public proof-of-concept code is available. The vulnerability is described in prose only; no synthetic exploit code is provided.

Detection Methods for CVE-2026-46047

Indicators of Compromise

Kernel oops or panic referencing qrtr_ns_data_ready, queue_work, or freed workqueue pointers
KASAN reports flagging use-after-free in net/qrtr/ns.c during module unload or shutdown
Unexpected kernel crashes coinciding with QRTR driver removal or system suspend/resume cycles

Detection Strategies

Enable KASAN on test kernels to surface use-after-free conditions in QRTR during teardown
Monitor dmesg and journalctl -k for stack traces involving qrtr_ns, process_one_work, or workqueue corruption
Inventory running kernel versions against the fixed commits to identify unpatched hosts

Monitoring Recommendations

Collect and centralize kernel ring buffer logs from Linux endpoints to spot crash signatures
Track module load and unload events for qrtr and qrtr_ns via auditd
Alert on repeated kernel panics on the same host, which can indicate exploitation attempts against race-condition flaws

How to Mitigate CVE-2026-46047

Immediate Actions Required

Apply the latest stable kernel update that includes the QRTR name service fix for your distribution
Identify systems using QRTR (typically Qualcomm-based platforms) and prioritize them for patching
If patching is delayed, avoid runtime unload of the qrtr and qrtr_ns modules on production systems

Patch Information

The fix has landed in multiple stable branches via the upstream commits 0f313eb, 2e127ce, 7809fea, db3c60e, and f96779e. The patch restores the default sk_data_ready callback at the start of remove() and ensures RX threads finish before destroy_workqueue() runs. Pull the fix from your distribution's kernel update channel.

Workarounds

Blacklist the qrtr and qrtr_ns modules on systems that do not require QRTR functionality
Restrict module removal privileges to trusted administrators only
Disable dynamic teardown paths that trigger driver removal during normal operation

bash

# Confirm running kernel and check for QRTR usage
uname -r
lsmod | grep -E 'qrtr|qrtr_ns'

# Prevent module load if QRTR is not required
echo 'blacklist qrtr'    | sudo tee /etc/modprobe.d/blacklist-qrtr.conf
echo 'blacklist qrtr_ns' | sudo tee -a /etc/modprobe.d/blacklist-qrtr.conf
sudo update-initramfs -u