CVE-2026-43196

What it actually does

This is a Linux kernel memory-corruption flaw in the Texas Instruments PRUSS support code. During pruss_clk_mux_setup(), an error path can release the same device-tree node reference twice: devm_add_action_or_reset() triggers pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np), and the caller then calls of_node_put(clk_mux_np) again. A double free/use-after-free condition in kernel context can corrupt kernel memory, potentially causing a denial of service through a kernel crash and, depending on allocator state and attacker control over the trigger conditions, may be usable for local privilege escalation or compromise of kernel integrity. The CVSS vector is local, low complexity, low privileges required, no user interaction, with high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems running affected Linux kernels with TI PRUSS hardware/driver support may be exposed to local kernel compromise or crashes. The most realistic operational risk is instability or denial of service on embedded, industrial, robotics, networking, or edge devices using TI SoCs with PRUSS functionality. Because exploitation requires local access and there is no known public exploit, no CISA KEV listing, no ransomware association, and EPSS is very low and flat at approximately 0.0014 over 30 days, this should be prioritized below remotely exploitable kernel flaws but still remediated through normal kernel maintenance, especially on multi-user or remotely administered devices.

How an attack unfolds

An attacker first needs local code execution with low privileges on a vulnerable Linux system where the affected PRUSS driver path is present and reachable. They then attempt to cause PRUSS clock mux setup to enter the failing initialization path that registers a managed cleanup action and immediately resets it. On that error path, the kernel releases the same device-tree node reference twice. If the double release only trips kernel safety checks, the result is likely a warning, refcount error, or crash. If the attacker can reliably shape kernel heap state around the double free, they may be able to turn the memory corruption into privilege escalation by corrupting kernel objects or control data. Current public intelligence indicates no known mature exploit and no known active exploitation campaigns for this issue.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the PRUSS double-free issue, identified in kernel changelogs as "soc: ti: pruss: Fix double free in pruss_clk_mux_setup()". Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the operating system, appliance, board-support-package, or embedded Linux vendor. For custom kernels, apply the upstream patch that returns directly after devm_add_action_or_reset() fails so that clk_mux_np is not released twice. If immediate patching is not possible, reduce exposure by disabling unused TI PRUSS support, removing or blacklisting the affected driver where operationally safe, limiting local shell access, restricting the ability to load/unload modules or rebind platform devices, and applying standard kernel hardening such as module signing, lockdown mode, least-privilege sudo policies, and mandatory access control.

How to confirm the fix worked

Confirm remediation by checking the running kernel package or source tree for the patch titled "soc: ti: pruss: Fix double free in pruss_clk_mux_setup()" and verifying that pruss_clk_mux_setup() does not call of_node_put(clk_mux_np) again after devm_add_action_or_reset() has already invoked the reset action on failure. On packaged systems, validate that the vendor advisory or changelog lists CVE-2026-43196 or the PRUSS double-free fix. Confirm whether exposure exists by checking whether the system uses a kernel with TI PRUSS support enabled and whether PRUSS-related devices are present in the device tree. After patching, reboot into the fixed kernel and verify the active kernel version with normal OS package and runtime checks rather than only confirming the installed package.

Typical attack path

1. Obtain local low-privileged execution on a Linux system using an affected kernel with TI PRUSS support present.
2. Identify whether the PRUSS driver and related device-tree configuration are available and can be probed, rebound, or otherwise initialized.
3. Trigger the PRUSS clock mux setup error path that invokes devm_add_action_or_reset() and the cleanup routine.
4. Cause the duplicate of_node_put() release of the same device-tree node reference.
5. Leverage the resulting kernel memory corruption to crash the system or attempt local privilege escalation, depending on exploit reliability.

How to detect it

Retrospective exploitation detection is difficult because successful kernel memory-corruption exploitation may leave few application-level artifacts. Focus on kernel and system logs, crash dumps, audit records, and endpoint telemetry. Review dmesg, journald, /var/log/kern.log, /var/log/messages, pstore/ramoops records, kdump/vmcore artifacts, and EDR telemetry for PRUSS driver initialization failures followed by refcount warnings, double-free reports, KASAN/KFENCE findings, slab corruption, general protection faults, or kernel panics. Look for local users or services repeatedly triggering device probing, driver unbind/bind operations, module load/unload activity, or device-tree overlay changes around the time of crashes. On hardened builds, correlate sudo, auditd, and shell history with access to /sys/bus/platform/drivers/, /sys/kernel/config/device-tree/overlays/, modprobe, insmod, rmmod, and PRUSS-related devices. There are no known threat actors, KEV exploitation, or public exploit campaigns associated with this issue based on the provided intelligence.

• pruss_clk_mux_setup
• pruss_of_free_clk_provider
• of_node_put
• KASAN: double-free
• KASAN: use-after-free
• refcount_t: underflow
• WARNING: CPU:
• BUG: kernel NULL pointer dereference
• general protection fault
• slab-use-after-free
• kernel BUG at
• Unable to handle kernel paging request
• /sys/bus/platform/drivers
• /sys/kernel/config/device-tree/overlays
• modprobe pruss
• rmmod pruss
• pru-rproc
• ti-pruss

What your security team should do

• Inventory Linux systems and embedded devices that run TI SoC board-support kernels or have PRUSS support enabled.
• Prioritize patching on systems where untrusted users, containers, services, or remote administrators can obtain local code execution.
• Apply the vendor-provided kernel update or backport the upstream PRUSS fix into custom kernels.
• Where PRUSS is not required, disable the driver or kernel configuration in future builds and block module loading where applicable.
• Monitor kernel logs for PRUSS initialization failures, double-free warnings, refcount underflow messages, KASAN reports, and unexplained kernel panics.
• Treat suspicious local activity around driver rebinding, module loading, device-tree overlays, or repeated PRUSS probe failures as potentially relevant until the system is patched.
• Because EPSS is low, there is no KEV listing, and no public exploit maturity is reported, handle this through scheduled kernel remediation unless the affected systems are exposed to untrusted local workloads.