CVE-2026-45914

What it actually does

This is a local Linux kernel vulnerability in the ibmpex hardware-monitoring driver involving unsafe lifetime handling of driver data exposed through sysfs sensor attributes. A race can occur when sensor attributes are being removed while a local userspace process reads sensor files such as temperature or voltage inputs. If the driver data is cleared or freed while a sysfs callback still dereferences it, the kernel may dereference invalid or NULL memory, leading to a kernel crash and potentially memory corruption. With successful exploitation, the impact is assessed as high for confidentiality, integrity, and availability because kernel memory corruption flaws can sometimes be shaped into local privilege escalation, although no public exploit maturity is currently indicated and EPSS is very low.

Why it matters to the business

Systems running affected Linux kernels with the ibmpex hardware-monitoring driver present may be exposed to local denial-of-service risk and, in worst-case scenarios, local privilege escalation. The practical exposure is narrower than a remote network flaw because an attacker needs local code execution or an existing low-privileged account, and the vulnerable driver must be present and reachable. Operationally, exploitation could crash servers, interrupt workloads, and create emergency maintenance events, especially on systems where hardware sensor monitoring is active. It is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, so remediation should be prioritized based on whether affected kernels and the ibmpex driver are deployed on important systems.

How an attack unfolds

An attacker first obtains local access to a Linux system, such as through a low-privileged shell, compromised service account, container escape prerequisite, or other foothold. They then determine whether the ibmpex hardware-monitoring driver is loaded and whether ibmpex-backed sysfs sensor files are present under hwmon paths. The attacker attempts to trigger a race between sysfs sensor reads and device or driver teardown by repeatedly reading sensor attributes while causing or waiting for removal, unload, or reinitialization activity. If the timing is successful, the sysfs callback may operate on cleared or freed driver data. The most likely visible result is a kernel oops, panic, or host crash. Depending on kernel build options, memory layout, and exploit reliability, a highly capable attacker may attempt to convert the memory-safety condition into kernel-mode code execution or privilege escalation, but no mature public exploitation is currently reported.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the upstream fix reverting the unsafe ibmpex change. No exact fixed package versions were provided in the input, so use the fixed kernel advisories from the operating system vendor, distribution security tracker, or hardware platform vendor. Where immediate patching is not possible, reduce exposure by unloading or blacklisting the ibmpex driver if it is not required, restricting local shell access to trusted users, limiting unprivileged access to hardware-monitoring sysfs paths where operationally feasible, and avoiding unnecessary driver reloads or device teardown operations on exposed systems. Because this is a kernel flaw, source-level application mitigations are not sufficient; remediation should occur through a patched kernel package or vendor-supported kernel stream.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed build for this issue, not only that a package has been installed. Verify after reboot with commands such as uname -a and distribution package queries. Check whether the ibmpex module is loaded using lsmod, modinfo ibmpex, or /sys/module/ibmpex, and confirm whether ibmpex-backed hwmon files are present under /sys/class/hwmon or device-specific sysfs paths. If a mitigation was chosen instead of patching, verify the module is unloaded and blacklisted persistently across reboots. Review kernel changelogs or distribution advisories for references to the ibmpex revert or the affected hwmon driver fix. A controlled non-production validation can include reading hwmon sensor files while loading and unloading the driver, but this should not be performed on production systems because it may intentionally trigger a kernel crash on vulnerable builds.

Typical attack path

1. Gain local execution on an affected Linux host with low privileges.
2. Check whether the ibmpex driver is available or loaded and whether hwmon sysfs sensor files are exposed.
3. Identify ibmpex-backed sensor attributes such as temperature, voltage, or fan sensor files under /sys/class/hwmon or related device paths.
4. Continuously read sensor sysfs files while attempting to trigger driver removal, device teardown, module unload, or a race-prone cleanup path.
5. Race the sysfs read callback against driver data cleanup so the kernel dereferences stale or NULL driver data.
6. Cause a kernel oops or panic, or attempt further exploitation if the memory corruption can be controlled.
7. Use resulting denial of service or possible elevated kernel privileges to disrupt workloads or expand control of the host.

How to detect it

To determine whether this was already exploited, review kernel logs, system journals, crash dumps, and audit records for crashes or oops events involving the ibmpex hardware-monitoring driver. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel records, kdump/vmcore artifacts, ABRT or apport crash records, auditd command execution logs, shell history where available, and EDR telemetry for local processes repeatedly reading hwmon sysfs paths. Look for kernel stack traces containing ibmpex_show_sensor, ibmpex, hwmon, sysfs read callbacks, NULL pointer dereference, general protection fault, slab use-after-free, or page fault messages. Correlate these events with local user sessions, repeated access to /sys/class/hwmon/hwmon*/ sensor files, modprobe/rmmod activity, service restarts involving hardware monitoring, or unexpected host reboots. Absence of these artifacts does not prove non-exploitation, because a successful denial-of-service may leave limited logs if the system panicked before flushing logs.

• ibmpex_show_sensor
• ibmpex
• hwmon: (ibmpex)
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• use-after-free
• KASAN: use-after-free
• dev_get_drvdata
• dev_set_drvdata
• device_remove_file
• /sys/class/hwmon/hwmon
• temp1_input
• temp2_input
• fan1_input
• in1_input
• rmmod ibmpex
• modprobe -r ibmpex
• /sys/module/ibmpex

What your security team should do

• Inventory Linux systems for affected kernel versions and for presence of the ibmpex hardware-monitoring driver.
• Prioritize patching systems where ibmpex is loaded, sensor sysfs files are exposed, or local multi-user access is permitted.
• Apply vendor-fixed kernel updates and reboot systems so the fixed kernel is actually running.
• If patching is delayed, unload and blacklist the ibmpex module where it is not operationally required.
• Restrict local interactive access and service-account shell access on systems that cannot be patched immediately.
• Monitor kernel logs for oops, panic, NULL pointer dereference, use-after-free, or stack traces referencing ibmpex or hwmon sysfs callbacks.
• Correlate suspicious kernel crashes with local user activity, repeated reads of /sys/class/hwmon files, and module unload or hardware-monitoring service activity.
• Track distribution advisories for exact fixed kernel package versions because no per-package fixed versions were supplied.
• Treat unexplained crashes on affected systems as potentially security-relevant until kernel logs and local activity are reviewed.