Description
In the Linux kernel, the following vulnerability has been resolved:

Revert "hwmon: (ibmpex) fix use-after-free in high/low store"

This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.

Jean Delvare points out that the patch does not completely
fix the reported problem, that it in fact introduces a
(new) race condition, and that it may actually not be needed in
the first place.

Various AI reviews agree. Specific and relevant AI feedback:

"
This reordering sets the driver data to NULL before removing the sensor
attributes in the loop below.

ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but
does not check if it is NULL before dereferencing it to access
data->sensors[].

If a userspace process reads a sensor file (like temp1_input) while this
delete function is running, could it race with the dev_set_drvdata(...,
NULL) call here and crash in ibmpex_show_sensor()?

Would it be safer to keep the original order where device_remove_file() is
called before clearing the driver data? device_remove_file() should wait
for any active sysfs callbacks to complete, which might already prevent the
use-after-free this patch intends to fix.
"

Revert the offending patch. If it can be shown that the originally reported
alleged race condition does indeed exist, it can always be re-introduced
with a complete fix.
Published: 2026-05-27
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The ibmpex hardware monitoring driver in the Linux kernel contains a race condition that can cause a null pointer dereference during the removal of sensor files. When a userspace process reads a sensor file while the driver is being unloaded, the driver data may be cleared to NULL before the sysfs callback finishes, leading to a kernel crash. This results in a denial‑of‑service that can affect the entire system.

Affected Systems

All Linux kernel versions that include the ibmpex driver are potentially impacted. No specific vendor version is listed; the issue is present in the kernel code where the ibmpex driver is compiled.

Risk and Exploitability

The CVSS score is not provided and the EPSS score is unavailable, but the vulnerability is not listed in the CISA KEV catalog. Attackers would need local access to trigger the race condition, for example by repeatedly reading sensor files during uncontrolled removal of the driver. The potential impact is a system crash, which can be considered a moderate risk in environments where the driver is used.

Generated by OpenCVE AI on May 27, 2026 at 16:34 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update to a Linux kernel version that includes the corrected ibmpex driver, which resolves the race condition without causing a null pointer dereference.
  • If an update cannot be applied immediately, disable the ibmpex driver so that sensor files are not exposed and cannot be accessed during removal.
  • Alternatively, remove or restrict permissions on the relevant sysfs entries (e.g., temp*_input) so that no userspace process can read them while the driver is being unregistered.

Generated by OpenCVE AI on May 27, 2026 at 16:34 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 27 May 2026 17:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416
CWE-476

Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: Revert "hwmon: (ibmpex) fix use-after-free in high/low store" This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: " This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data->sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. " Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.
Title Revert "hwmon: (ibmpex) fix use-after-free in high/low store"
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-27T12:17:29.426Z

Reserved: 2026-05-13T15:03:33.085Z

Link: CVE-2026-45914

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:06.180

Modified: 2026-05-27T14:48:03.013

Link: CVE-2026-45914

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-27T16:45:38Z

Weaknesses