<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T14:53:22.698697+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2024-58262</id>
    <title>CVE-2024-58262</title>
    <updated>2026-10-03T14:53:22.700329+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> dalek-cryptography curve25519-dalek</p>
<p>The curve25519-dalek crate before 4.1.3 for Rust has a constant-time operation on elliptic curve scalars that is removed by LLVM.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2024-58262"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-x4gp-pqpj-f43q</id>
    <title>GHSA-x4gp-pqpj-f43q — curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`</title>
    <updated>2026-10-03T14:53:22.700387+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: curve25519-dalek</p>
<p>Timing variability of any kind is problematic when working with  potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in `curve25519-dalek`.</p>
<p>The `Scalar29::sub` (32-bit) and `Scalar52::sub` (64-bit) functions contained usage of a mask value inside a loop where LLVM saw an opportunity to insert a branch instruction (`jns` on x86) to conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt:</p>
<p>- 32-bit (see L106): https://godbolt.org/z/zvaWxzvqv
- 64-bit (see L48): https://godbolt.org/z/PczYj7Pda</p>
<p>A similar problem was recently discovered in the Kyber reference implementation:</p>
<p>https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ</p>
<p>As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away.</p>
<p>The fix can be validated in godbolt here:</p>
<p>- 32-bit: https://godbolt.org/z/jc9j7eb8E
- 64-bit: https://godbolt.org/z/x8d46Yfah</p>
<p>The problem was discovered and the solution independently verified by Alexander Wagner &lt;alexander.wagner@aisec.fraunhofer.de&gt; and Lea Themint &lt;lea.thiemt@tum.de&gt; using their DATA tool:</p>
<p>https://github.com/Fraunhofer-AISEC/DATA</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-x4gp-pqpj-f43q"/>
  </entry>
</feed>
