CVE-2026-31770

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel hwmon OCC driver. In occ_show_power_1(), the driver can divide an accumulated power value by update_tag without first confirming that update_tag is nonzero. If the OCC hardware monitoring sensor block is present but has not yet collected samples, such as during early boot or immediately after sensor initialization, reading the affected power sensor sysfs attribute can trigger a kernel divide-by-zero exception. The likely result is a kernel oops or panic, depending on system configuration, causing loss of availability. The flaw does not provide confidentiality or integrity impact and does not enable remote code execution or privilege escalation by itself.

Why it matters to the business

Systems using affected Linux kernel versions with the OCC hardware monitoring driver exposed may be vulnerable to local crashes triggered by an authenticated local user or process that can read the relevant hardware monitoring sysfs sensor attribute. Operationally, this can cause unexpected server reboots, workload interruption, failed jobs, or service downtime on affected platforms. The CVSS score is moderate, EPSS is very low and stable, there is no known CISA KEV listing, no known ransomware association, and no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, the impact can still be significant for high-availability Linux systems where local users, monitoring agents, or automated inventory tools routinely read hwmon sensor files.

How an attack unfolds

An attacker first needs local access to an affected Linux system, or the ability to cause a local process or monitoring component to read the vulnerable hwmon OCC power sensor attribute. The vulnerable condition occurs when the OCC sensor data structure exists but no samples have been collected, leaving update_tag equal to zero. The attacker then reads the affected power input/average sysfs file exposed by the OCC hwmon driver at the right time, commonly soon after boot or sensor initialization. The kernel executes occ_show_power_1(), attempts to divide by update_tag, and triggers a divide-by-zero exception. Depending on kernel panic settings and system configuration, this may crash the kernel immediately or produce an oops that destabilizes the system, resulting in denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the fix for the OCC hwmon driver division-by-zero in occ_show_power_1(). The upstream fix changes occ_show_power_1() to use the existing occ_get_powr_avg() helper, which safely handles the zero-sample case. No exact fixed package versions were provided in the input, so organizations should consult their Linux distribution, appliance vendor, or kernel supplier advisories for the first fixed kernel build for their supported release stream. Where immediate kernel upgrade is not possible, reduce exposure by restricting untrusted local shell access, limiting container or workload access to host sysfs, reviewing permissions and mount propagation for /sys, and disabling or unloading the OCC hwmon driver only if it is not operationally required. Avoid relying solely on monitoring suppression as a fix, because any permitted local read path that reaches the vulnerable attribute may still trigger the crash.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor backport or upstream fix for the OCC hwmon occ_show_power_1() path. Check the active kernel version with uname -r and compare it with the fixed versions in the relevant distribution advisory. On source-based or custom kernels, confirm that occ_show_power_1() no longer divides directly by update_tag and instead uses the safe occ_get_powr_avg() helper or equivalent zero-checking logic. Validate exposure by checking whether the OCC hwmon driver is present and loaded and whether OCC-related hwmon entries exist under /sys/class/hwmon/. In controlled non-production testing only, read the relevant OCC power sensor attributes shortly after boot and confirm that the system does not log divide errors, kernel oops messages, or panic. Do not perform crash-triggering validation on production systems.

Typical attack path

1. Obtain local authenticated access to a Linux system running an affected kernel with the OCC hwmon driver in use.
2. Identify exposed hwmon sysfs entries associated with OCC power sensors, typically under /sys/class/hwmon/ or /sys/devices/.
3. Wait for or induce a timing window where the OCC sensor block is present but no samples have been collected yet, such as shortly after boot or driver initialization.
4. Read the affected power sensor attribute that invokes occ_show_power_1().
5. Trigger a divide-by-zero exception in kernel space when update_tag is zero.
6. Cause a kernel oops or panic, leading to system instability, reboot, or service outage.

How to detect it

To determine whether exploitation or accidental triggering has already occurred, review kernel logs, persistent journal logs, crash dumps, and system reboot records for divide-by-zero exceptions or kernel oops/panic events involving the OCC hwmon driver. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, kdump/vmcore artifacts, pstore/ramoops logs, and systemd journal boot history. Look for crashes occurring shortly after boot, driver initialization, or monitoring-agent startup, especially if preceded by reads of hwmon sysfs paths. If auditd or eBPF/syscall telemetry is available, search for processes reading /sys/class/hwmon/*/power* or OCC-related sysfs files immediately before a crash. Monitoring agents, inventory tools, health checks, and local users may accidentally trigger the issue, so correlate kernel exceptions with process execution logs and recent sensor-collection activity. There are no known public threat actors or ransomware campaigns associated with this vulnerability based on the provided data.

• divide error: 0000
• divide error
• kernel BUG
• Oops: divide error
• Kernel panic - not syncing
• occ_show_power_1
• occ_get_powr_avg
• hwmon: (occ)
• /sys/class/hwmon/
• /sys/class/hwmon/*/power
• /sys/class/hwmon/*/power*_input
• /sys/class/hwmon/*/power*_average
• /sys/devices/*/hwmon/*/power
• /sys/devices/*/hwmon/*/power*_input
• /sys/devices/*/hwmon/*/power*_average

What your security team should do

• Prioritize patching affected Linux kernels on systems that expose OCC hwmon sensors, especially high-availability servers and systems with local multi-user access.
• Ask Linux distribution or platform vendors for the exact fixed kernel builds if package-level fixed versions are not yet documented internally.
• Inventory systems for loaded OCC hwmon support and exposed /sys/class/hwmon power sensor attributes to determine whether the vulnerable driver path is reachable.
• Restrict untrusted local access and review container, workload, and monitoring-agent access to host /sys while patches are being deployed.
• Monitor kernel logs for divide-by-zero, oops, or panic events involving the OCC hwmon driver or occ_show_power_1().
• Treat unexpected reboots on affected platforms shortly after boot or monitoring startup as potentially related until logs confirm another cause.
• Because EPSS is very low, no KEV listing exists, and no exploit maturity is reported, handle this as a targeted local availability risk rather than an urgent internet-facing remote exploitation event.