CVE-2026-46047

What it actually does

This is a Linux kernel use-after-free in the QRTR name service remove path. During driver or module removal, a packet can arrive after the QRTR workqueue has been destroyed but before the socket is released. The socket data-ready callback can then attempt to queue work on freed structures, potentially corrupting kernel memory. Because the flaw is local, low-complexity, and requires low privileges, a successful exploit could cause a kernel crash or, depending on kernel configuration and memory layout, potentially enable local privilege escalation with kernel-level code execution.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local denial of service or possible privilege escalation. The most likely operational impact is unexpected host crashes, reboots, or instability on systems using QRTR functionality, particularly platforms that rely on Qualcomm IPC Router components. This issue is not currently listed in CISA KEV, has no known mature public exploit, and has a very low EPSS score, so internet-scale exploitation is unlikely; however, it still matters for shared servers, developer workstations, edge devices, and appliances where untrusted or semi-trusted local users can run code.

How an attack unfolds

An attacker first needs local code execution with low privileges on a vulnerable Linux system. They then attempt to interact with QRTR-related functionality while inducing or racing driver/module removal. The vulnerable timing window occurs after the QRTR name service workqueue is destroyed but before the associated socket is released. If a QRTR packet is delivered during this window, the registered data-ready callback can dereference a freed work structure. In a basic attack, this can trigger a kernel oops or panic, causing denial of service. A more advanced attacker may attempt to shape heap layout and timing to turn the use-after-free into controlled kernel memory corruption and possible privilege escalation.

How to fix it

Upgrade to a Linux kernel version or vendor backport that includes the QRTR name service remove-path fix for this issue. Because no exact fixed versions were provided, rely on the relevant distribution, appliance, or kernel vendor advisory and confirm that the patch for `net: qrtr: ns: Fix use-after-free in driver remove()` is included. Where immediate patching is not possible, reduce exposure by disabling or unloading QRTR-related modules if they are not required, preventing untrusted users from loading or unloading kernel modules, restricting local shell access, and applying standard kernel hardening features such as module signing, lockdown mode, SELinux/AppArmor confinement, and rapid reboot recovery for crash-prone systems. Do not rely on mitigation alone for multi-user systems; apply the kernel fix as the durable remediation.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version after reboot with `uname -r` and comparing it to the vendor-fixed package or advisory. Review the kernel package changelog or source tree for the patch titled `net: qrtr: ns: Fix use-after-free in driver remove()`. On source-based or custom kernels, verify that the QRTR name service remove path restores the original `sk_data_ready` callback before destroying the workqueue and ensures RX threads complete before workqueue destruction. In non-production testing, validate that repeated QRTR module or driver teardown under QRTR traffic does not produce KASAN warnings, kernel oopses, or panics. Also verify whether QRTR modules are absent or disabled on systems where mitigation was chosen instead of patching.

Typical attack path

1. Gain local low-privileged execution on a Linux host running an affected kernel.
2. Identify whether QRTR support is present, loaded, or reachable on the system.
3. Generate QRTR socket activity or packets that can trigger the QRTR name service data-ready path.
4. Induce or wait for QRTR driver/module removal, device removal, or subsystem teardown.
5. Race packet delivery into the window after workqueue destruction and before socket release.
6. Trigger use-after-free in the QRTR name service callback.
7. Cause a kernel crash or attempt to exploit kernel memory corruption for privilege escalation.

How to detect it

Detecting prior exploitation is difficult because successful exploitation may leave only kernel crash artifacts or memory-corruption symptoms. Review kernel logs from `journald`, `/var/log/kern.log`, `/var/log/messages`, `dmesg`, crash dumps, and `kdump`/`vmcore` outputs for QRTR-related oopses, panics, KASAN reports, or use-after-free messages. Correlate these events with audit logs for module load/unload activity, device removal, service restarts, local user logins, suspicious process execution, and any `modprobe`, `rmmod`, `insmod`, or `delete_module` activity near the crash time. On systems with EDR or auditd, look for low-privileged users repeatedly interacting with QRTR sockets or attempting to trigger kernel module teardown. Treat unexplained privilege changes, new root-owned files, persistence mechanisms, or post-crash tampering as possible follow-on activity, but there are no unique network indicators for this local kernel race condition.

• BUG: KASAN: use-after-free
• use-after-free in qrtr_ns_data_ready
• qrtr_ns_data_ready
• qrtr_ns_remove
• net: qrtr: ns
• qrtr
• Call Trace: qrtr_ns_data_ready
• kernel BUG
• Oops:
• general protection fault
• Unable to handle kernel paging request
• Kernel panic - not syncing
• modprobe qrtr
• rmmod qrtr
• insmod qrtr
• delete_module

What your security team should do

• Prioritize patching on multi-user Linux systems, systems that allow local code execution by untrusted users, and devices that use Qualcomm/QRTR-related functionality.
• Track the applicable Linux distribution or vendor advisory and deploy the kernel containing the QRTR name service use-after-free fix.
• After installing the updated kernel, reboot systems and verify the fixed kernel is the running kernel.
• If QRTR is not operationally required, disable or blacklist QRTR-related modules as a temporary mitigation, subject to vendor supportability constraints.
• Harden local attack surface by limiting shell access, enforcing least privilege, restricting kernel module operations, and enabling kernel lockdown or module signing where supported.
• Monitor kernel logs and crash dumps for QRTR-related oops, panic, or KASAN use-after-free messages, especially around module removal or device teardown events.
• Because current EPSS is low and there is no KEV listing or known exploit maturity, treat this as important kernel hygiene rather than an emergency internet-facing exposure unless local untrusted users are present.