CVE-2026-43242

What it actually does

This is a local availability flaw in the Linux kernel TI K3 SoC information driver. During driver probe, an MMIO regmap allocation is not released if probe fails, such as during probe deferral or failed driver initialization. Repeated failure paths can leak kernel memory over time and may eventually cause memory pressure, degraded system behavior, or denial of service. The issue does not directly provide confidentiality or integrity impact and is not remotely exploitable based on the provided scoring.

Why it matters to the business

Systems running affected Linux kernels on platforms that use the TI K3 SoC information driver may become unstable if the vulnerable probe failure path is repeatedly exercised. The likely business impact is service degradation, device instability, or outages on affected embedded, edge, appliance, or industrial Linux systems. The risk is moderated by local access requirements, low EPSS, no known public exploitation, and no CISA KEV listing, but availability-sensitive deployments should still prioritize kernel updates during normal maintenance windows.

How an attack unfolds

An attacker must already have local access to an affected Linux system and a way to influence driver probing, unbinding, rebinding, device initialization, or conditions that cause probe failure or deferral. The attacker repeatedly triggers the vulnerable probe failure path in the TI K3 SoC information driver. Each failed probe leaks the allocated MMIO regmap instead of releasing it. Over repeated attempts, unreclaimed kernel memory accumulates, potentially causing memory pressure, OOM activity, degraded performance, or a system-level denial of service. There is no indication from the supplied data that this vulnerability is being used by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a Linux kernel version from the distribution, device vendor, or kernel maintainer that includes the fix for the TI K3 SoC information driver regmap lifetime bug. The corrected implementation uses device-managed allocation so the regmap is released automatically on probe failure and driver unbind. No exact fixed package versions were provided, so track the advisory from the relevant Linux distribution, BSP vendor, embedded device vendor, or long-term kernel branch. If immediate patching is not possible, reduce local interactive access, restrict administrative interfaces that can bind or unbind platform drivers, disable unused vulnerable driver functionality where operationally safe, and monitor affected systems for repeated probe failures and memory pressure.

How to confirm the fix worked

Confirm the running kernel package or source tree contains the vendor fix for the TI K3 SoC information driver regmap leak. Validate exposure by checking whether the platform uses the TI K3 SoC information driver and whether the driver is built into the kernel or loaded as a module. After updating, reboot into the fixed kernel and verify with uname, package inventory, or vendor kernel build metadata. For deeper validation, reproduce a controlled probe-failure or driver-unbind test in a non-production environment and confirm kernel memory usage does not grow across repeated failed probe attempts. Also review kernel logs after reboot for absence of recurring k3-socinfo probe failure, deferred probe, memory allocation, or OOM messages.

Typical attack path

1. Obtain local access to an affected Linux system.
2. Identify that the running kernel includes the vulnerable TI K3 SoC information driver path.
3. Trigger repeated driver probe failures, probe deferrals, or bind/unbind-related initialization failures where permitted.
4. Cause incremental kernel memory leakage on each failed probe attempt.
5. Continue until the system experiences memory pressure, service instability, OOM kills, or denial of service.

How to detect it

To assess possible prior exploitation or abuse, review kernel logs, system journals, audit logs, and endpoint telemetry for repeated TI K3 SoC information driver probe failures, deferred probes, driver unbind or bind events, unexplained memory pressure, and OOM killer activity. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, auditd records for writes to sysfs driver bind/unbind files, and EDR telemetry for local users or scripts repeatedly manipulating platform driver interfaces. Focus on sequences where k3-socinfo-related probe errors or deferred probes are followed by steadily declining free memory, slab growth, OOM kills, service restarts, or host instability. There are no known public exploit-specific payload indicators from the provided data, so detection should emphasize behavioral evidence of repeated local triggering and resulting availability impact.

• k3-socinfo
• /sys/bus/platform/drivers/k3-socinfo/bind
• /sys/bus/platform/drivers/k3-socinfo/unbind
• deferred probe
• probe deferral
• probe failed
• Out of memory
• oom-killer
• Killed process

What your security team should do

• Inventory Linux systems, appliances, and embedded devices that run TI K3-based kernels or include the k3-socinfo driver.
• Prioritize remediation for systems where availability is critical, where local users or workloads are less trusted, or where driver bind/unbind operations are exposed to operators or automation.
• Apply the vendor-provided kernel, BSP, or firmware update that includes the regmap leak fix; reboot systems into the fixed kernel.
• If patching is delayed, restrict local shell access and privileged sysfs access that could be used to manipulate platform driver binding or trigger repeated probe attempts.
• Add monitoring for repeated k3-socinfo probe failures, driver bind/unbind activity, increasing kernel memory pressure, and OOM killer events.
• Because EPSS is low, exploit maturity is listed as none, and the issue is not in CISA KEV, handle through risk-based patch management unless the affected device provides critical services.