<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T07:27:09.972442+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-45914</id>
    <title>CVE-2026-45914 — Revert "hwmon: (ibmpex) fix use-after-free in high/low store"</title>
    <updated>2026-09-29T07:27:09.977326+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>Revert "hwmon: (ibmpex) fix use-after-free in high/low store"</p>
<p>This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.</p>
<p>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.</p>
<p>Various AI reviews agree. Specific and relevant AI feedback:</p>
<p>"
This reordering sets the driver data to NULL before removing the sensor
attributes in the loop below.</p>
<p>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-&gt;sensors[].</p>
<p>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()?</p>
<p>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.
"</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-45914"/>
  </entry>
</feed>
