CVE-2026-98200
hwmon: (hp-wmi-sensors) Fix use-after-free in fungible_show()
No known exploitation. EPSS puts it in the 7th percentile. Fixed versions are out.
What to do
Find your product and version, then upgrade to the build on the right.
- LinuxAffected: ≥ 23902f98f8d4811ab84dde6419569a5b374f8122, < b6b2a638aa36c441b2c8d0b6bd8ed2bb9701e795Upgrade to: b6b2a638aa36c441b2c8d0b6bd8ed2bb9701e795Affected: ≥ 23902f98f8d4811ab84dde6419569a5b374f8122, < f59ecfd2c58bace39538f3fff7f43788b3fdb539Upgrade to: f59ecfd2c58bace39538f3fff7f43788b3fdb539Affected: ≥ 23902f98f8d4811ab84dde6419569a5b374f8122, < 72c85149794a1ccf8d718ffed1521106b5d31968Upgrade to: 72c85149794a1ccf8d718ffed1521106b5d31968Affected: ≥ 23902f98f8d4811ab84dde6419569a5b374f8122, < 9c1e65bc79ff104914b11e6ad972139296ec86feUpgrade to: 9c1e65bc79ff104914b11e6ad972139296ec86fe + 1 more branchStated by: CVE record
Versions as the sources state them. Full version matrix after sign-in
What it is
From the CVE record
In the Linux kernel, the following vulnerability has been resolved: hwmon: (hp-wmi-sensors) Fix use-after-free in fungible_show() nsensor->current_state is dynamically replaced as the sensor's state changes. update_numeric_sensor_from_wobj() does this by freeing the old string and installing a new one: if (strcmp(trimmed, nsensor->current_state)) { new_string = hp_wmi_strdup(dev, trimmed); if (new_string) { devm_kfree(dev, nsensor->current_state); nsensor->current_state = new_string; } } This function is only ever called from hp_wmi_update_info() while state->lock is held, so the free-and-replace itself is properly serialized against concurrent updates. fungible_show(), however, reads the same pointer after the lock has already been dropped: err = hp_wmi_update_info(state, info); if (err) return err; switch (prop) { ... case HP_WMI_PROPERTY_CURRENT_STATE: seq_printf(seqf, "%s\n", nsensor->current_state); break; hp_wmi_update_info() takes state->lock internally and releases it before returning, so by the time fungible_show() dereferences nsensor->current_state in seq_printf(), no lock is held. Two processes reading a sensor's current_state debugfs entry at overlapping times (or one reading it while another read of the same sensor triggers a refresh) can race: one thread's seq_printf() can be part-way through printing the string at the moment another thread's call into update_numeric_sensor_from_wobj() frees it with devm_kfree() and installs a new pointer, causing a use-after-free read. Take state->lock around the read in fungible_show() as well, so it can never run concurrently with the free-and-replace in update_numeric_sensor_from_wobj().
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.2% chance of exploitation activity in the next 30 days, which ranks it in the 7th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
2 events over 0 days, from the signal feeds we watch.
- Publishedrecord updated
Affected products
Sources
References in the record
- git.kernel.org/stable/c/b6b2a638aa36c441b2c8d0b6bd8ed2bb9701e795
- git.kernel.org/stable/c/f59ecfd2c58bace39538f3fff7f43788b3fdb539
- git.kernel.org/stable/c/72c85149794a1ccf8d718ffed1521106b5d31968
And 2 more references. See all after sign-in
In the news
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Linux, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI