Skip to main content

Linux Kernel CVE-2026-45914

| EUVDEUVD-2026-32380 HIGH
Use After Free (CWE-416)
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-wf7m-gffh-f29c
7.8
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
4.7 MEDIUM

Local low-priv access (AV:L/PR:L); winning a narrow teardown race makes AC:H; realistic impact is a kernel crash, so A:H with C:N/I:N.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
4.7 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 24, 2026 - 15:10 vuln.today
CVSS changed
Jun 24, 2026 - 15:07 NVD
7.8 (HIGH)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
HIGH 7.8
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)

DescriptionNVD

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.

AnalysisAI

Local memory corruption affects the Linux kernel's hwmon ibmpex driver, where commit 6946c726c3f4 - intended to fix a use-after-free in the high/low sysfs store handlers - instead introduced a new race condition by setting driver data to NULL before removing sensor attributes. The remediation is a revert of that flawed commit across the 6.1, 6.6, 6.12, 6.18, and 6.19 stable trees. With EPSS at 0.02% (7th percentile), no public exploit identified at time of analysis, and no CISA KEV listing, real-world risk is minimal given the obscure IBM PowerExecutive sensor hardware the driver targets.

Technical ContextAI

The affected component is the ibmpex hwmon driver (drivers/hwmon/ibmpex.c), which exposes IBM PowerExecutive power/thermal sensor data through sysfs attributes such as temp1_input. The root cause class is CWE-416 (Use-After-Free), here manifesting as a teardown race: the reverted patch reordered driver removal so that dev_set_drvdata(..., NULL) executed before device_remove_file() removed the sysfs attributes. Because ibmpex_show_sensor() retrieves driver data via dev_get_drvdata() and dereferences data->sensors[] without a NULL check, a concurrent userspace read of a sensor file during driver removal could race the NULL assignment and crash. Maintainer Jean Delvare noted the original ordering - device_remove_file() before clearing driver data - is actually safer, since device_remove_file() blocks until active sysfs callbacks complete, likely meaning the originally reported UAF never existed. CPE data scopes this to Linux kernel 6.19 and its release candidates rc2-rc4.

RemediationAI

Apply the vendor-released stable kernel update containing the revert: patched versions are 5.10.252, 6.1.165, 6.6.128, 6.12.75, 6.18.14, 6.19.4, and 7.0. Upgrade to the fixed release for your branch and reboot into the new kernel; the corresponding upstream fixes are the stable commits at https://git.kernel.org/stable/c/894d9c7aab68fd0c70c78b1d03c8fa589fb0f67d, https://git.kernel.org/stable/c/8bde3e395a85017f12af2b0ba5c3684f5af9c006, https://git.kernel.org/stable/c/914b47c9b824d3d74f31c764163edf93302100b1, https://git.kernel.org/stable/c/05112ba67c824ab416cd54307c0b50aba9f0047a, https://git.kernel.org/stable/c/efd68429f23fb4015b0ebc2392334059e06fad18, https://git.kernel.org/stable/c/f448acd86835a650f9ea83460b9ca347d3aafba5, and https://git.kernel.org/stable/c/14a38784e09aebc21207dc32fffa05247fc3dd64. If you cannot patch immediately and lack IBM PowerExecutive hardware, the practical compensating control is to ensure the ibmpex module is not loaded (blacklist it via modprobe), which removes the attack surface entirely with no functional loss on such systems; on systems that do use it, restrict local shell access and avoid driver unbind/rebind operations while sensor files may be read concurrently, accepting that this only narrows rather than closes the race window.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Not-Affected

Share

CVE-2026-45914 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy