<?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-29T22:16:06.025735+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-2025-38252</id>
    <title>CVE-2025-38252 — cxl/ras: Fix CPER handler device confusion</title>
    <updated>2026-09-29T22:16:06.040454+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>cxl/ras: Fix CPER handler device confusion</p>
<p>By inspection, cxl_cper_handle_prot_err() is making a series of fragile
assumptions that can lead to crashes:</p>
<p>1/ It assumes that endpoints identified in the record are a CXL-type-3
   device, nothing guarantees that.</p>
<p>2/ It assumes that the device is bound to the cxl_pci driver, nothing
   guarantees that.</p>
<p>3/ Minor, it holds the device lock over the switch-port tracing for no
   reason as the trace is 100% generated from data in the record.</p>
<p>Correct those by checking that the PCIe endpoint parents a cxl_memdev
before assuming the format of the driver data, and move the lock to where
it is required. Consequently this also makes the implementation ready for
CXL accelerators that are not bound to cxl_pci.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2025-38252"/>
  </entry>
</feed>
