CVE-2026-43041

What it actually does

This is a local Linux kernel denial-of-service flaw in the QRTR networking subsystem. The vulnerable code uses the deprecated radix tree API for qrtr_tx_flow tracking; when internal radix-tree node allocation partially succeeds and a later allocation fails, already-linked internal nodes can be left orphaned and are not reclaimed during normal cleanup. A local low-privileged user able to exercise the affected QRTR paths can cause unreclaimed kernel memory growth, potentially exhausting memory and degrading or crashing the host. The flaw does not directly provide confidentiality or integrity impact, and the CVSS vector indicates local access with low privileges is required.

Why it matters to the business

Successful exploitation can make Linux systems unstable or unavailable by consuming kernel memory, causing service outages, process termination by the out-of-memory killer, host reboots, or degraded performance. The current public exploitation signal is low: EPSS is approximately 0.00114, unchanged over 30 days, it is not listed in CISA KEV, and no mature public exploit is indicated. However, because the affected component is in the kernel, exploitation on shared systems, multi-user servers, developer workstations, edge devices, or container hosts could affect many workloads on the same machine.

How an attack unfolds

An attacker first needs local execution with at least a low-privileged account on a vulnerable Linux kernel. They then repeatedly exercise QRTR transmit-flow behavior in a way that forces radix-tree growth and allocation attempts. Under memory pressure or repeated triggering, the vulnerable allocation sequence can leave intermediate radix-tree nodes linked without corresponding leaf entries. Because the cleanup path only visits leaf slots, these orphaned internal nodes remain allocated. By repeating the operation, the attacker can steadily leak kernel memory until the system experiences memory pressure, kills processes, becomes unresponsive, or reboots. There is no indication from the supplied intelligence that this vulnerability is being used by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a kernel version or vendor backport that contains the QRTR fix replacing qrtr_tx_flow radix_tree usage with xarray cleanup semantics. No exact fixed package versions were provided, so use the relevant Linux distribution, appliance, or kernel vendor advisory to identify the corrected kernel build. After patching, reboot into the fixed kernel; merely installing a kernel package is not sufficient if the system continues running the vulnerable kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access to trusted users, restricting untrusted workloads on affected hosts, isolating multi-tenant/container workloads, monitoring memory pressure, and disabling or removing QRTR support only if it is not required and the platform/vendor supports doing so safely.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is fixed. Validate with commands such as uname -a and the distribution package manager, then compare against the vendor advisory or changelog for the fix text 'net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak'. For source-based kernels, verify the QRTR transmit-flow implementation uses xarray cleanup rather than the vulnerable radix-tree pattern. Reboot after applying the update and confirm the active kernel version changed. If regression testing is possible, run QRTR-related functional tests while monitoring kernel memory usage, slab growth, dmesg, and out-of-memory events to confirm memory no longer grows unexpectedly under repeated QRTR activity.

Typical attack path

1. Obtain local code execution on a vulnerable Linux system as a low-privileged user.
2. Confirm that the running kernel includes the vulnerable QRTR radix-tree implementation.
3. Trigger QRTR transmit-flow operations repeatedly, especially under conditions that increase allocation failure likelihood.
4. Cause orphaned radix-tree internal nodes to accumulate in kernel memory.
5. Continue until kernel memory pressure leads to service degradation, out-of-memory kills, host instability, or denial of service.

How to detect it

There are no highly specific public indicators of compromise for this issue from the supplied intelligence, and exploitation may resemble ordinary memory pressure rather than a distinctive intrusion. To investigate possible prior exploitation, review kernel logs, system journals, and monitoring telemetry for unexplained kernel memory growth, repeated out-of-memory events, host hangs, or reboots without a clear workload cause. Correlate these events with local user activity, container starts, unusual processes, or workload changes immediately before memory exhaustion. Useful log sources include dmesg, journalctl/kern.log, syslog/messages, auditd process execution logs, EDR process telemetry, container runtime logs, and memory/slab monitoring. Pay particular attention to systems where low-privileged users or untrusted containers were active and where QRTR-related kernel functionality was present. Because the vulnerability is a kernel memory leak, absence of file artifacts does not rule out exploitation.

• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• Kernel panic - not syncing
• systemd-journald: Journal stopped
• qrtr
• AF_QIPCRTR
• PF_QIPCRTR
• qmi
• Memory allocation failure

What your security team should do

• Prioritize patching shared Linux hosts, container platforms, build systems, bastion hosts, developer workstations, and any systems where untrusted local users or workloads can execute code.
• Track the applicable distribution or vendor kernel advisory because exact fixed versions were not supplied in the input.
• After patch deployment, reboot systems and verify the active running kernel is the corrected version.
• Until patched, limit local interactive access and avoid running untrusted workloads on affected systems where practical.
• Monitor for unexplained kernel memory growth, OOM-killer activity, host hangs, and repeated QRTR-related activity by low-privileged processes.
• Because EPSS is low, there is no KEV listing, and no exploit maturity is reported, treat this as important availability-risk remediation rather than an emergency internet-wide exploitation event.