<?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-10-01T12:37:19.652533+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-39715</id>
    <title>CVE-2025-39715 — parisc: Revise gateway LWS calls to probe user read access</title>
    <updated>2026-10-01T12:37:19.654874+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux, Siemens SIMATIC CN 4100</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>parisc: Revise gateway LWS calls to probe user read access</p>
<p>We use load and stbys,e instructions to trigger memory reference
interruptions without writing to memory. Because of the way read
access support is implemented, read access interruptions are only
triggered at privilege levels 2 and 3. The kernel and gateway
page execute at privilege level 0, so this code never triggers
a read access interruption. Thus, it is currently possible for
user code to execute a LWS compare and swap operation at an
address that is read protected at privilege level 3 (PRIV_USER).</p>
<p>Fix this by probing read access rights at privilege level 3 and
branching to lws_fault if access isn't allowed.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2025-39715"/>
  </entry>
</feed>
