Cloudanix VulnDB

CVE-2026-93142

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding mistake in a chip temperature driver can make the computer crash when the driver fails to start correctly.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Error-handling flaw in the rcar thermal driver probe path calls thermal_zone_device_enable before validating the result of thermal_zone_device_register_with_trips, causing an error-pointer dereference of priv->zone and a subsequent kernel oops or panic.

Why it matters to the business

Systems using the affected Renesas R-Car thermal driver may experience unexpected kernel crashes during driver initialization or removal, leading to reduced availability and potential data loss on affected hardware platforms.

How an attack unfolds

An attacker with the ability to trigger driver probe (typically via module load or device discovery) can force the error path in probe by arranging for thermal_zone_device_register_with_trips to fail; the subsequent unconditional enable call then dereferences an error pointer, resulting in a kernel crash. No public exploits or threat-actor campaigns are known.

How to fix it

Apply the upstream fix that moves the thermal_zone_device_enable call after the register check and uses a unified error path. Rebuild and deploy an updated kernel containing the corrected rcar thermal driver code.

How to confirm the fix worked

Confirm the patch is present by inspecting the rcar_thermal_probe function for the corrected call ordering; boot the patched kernel on affected hardware and verify that probe failures no longer produce an error-pointer dereference.

Typical attack path

  1. Obtain local or physical access sufficient to cause the rcar_thermal module to be loaded or reprobed.
  2. Induce a failure in thermal_zone_device_register_with_trips (e.g., via resource exhaustion or malformed device-tree data).
  3. Trigger the buggy probe path that calls thermal_zone_device_enable on the error pointer.
  4. Kernel dereferences the error pointer, producing an oops and potential system panic.

How to detect it

Review kernel logs for oops or panic messages referencing rcar_thermal_probe, thermal_zone_device_enable, or priv->zone shortly after module load; correlate with device-tree or hardware enumeration events.

What your security team should do

  • Prioritize kernel updates for any fleet containing Renesas R-Car SoCs.
  • Monitor vendor BSP releases for the backported fix.
  • Test driver error paths in staging environments before wide deployment.

The record

In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of "priv->zone". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly.

Affected packages

Ecosystem Package Introduced Fixed