<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 10:00:39 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-74578 — crypto: algif_skcipher - force synchronous processing on trees without ctx-&gt;state</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-74578</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;crypto: algif_skcipher - force synchronous processing on trees without ctx-&amp;gt;state&lt;/p&gt;
&lt;p&gt;The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx-&amp;gt;iv
directly into the skcipher request. After io_submit() the socket lock is
dropped and the request is processed asynchronously, so a concurrent
sendmsg(ALG_SET_IV) can overwrite ctx-&amp;gt;iv and make the in-flight request
run under an attacker-controlled IV. For CTR/stream modes this is
IV/keystream reuse and lets an unprivileged user recover the plaintext of
a concurrent operation.&lt;/p&gt;
&lt;p&gt;Snapshotting ctx-&amp;gt;iv into per-request storage for the async path is not
sufficient. For ciphers with statesize == 0 - which includes cbc and ctr -
the MSG_MORE inter-chunk IV chaining is carried solely by the in-place
req-&amp;gt;iv writeback, which a snapshot redirects into per-request memory that
af_alg_free_resources() releases on completion, silently producing wrong
output. Writing the IV back from the completion callback instead is not
possible either: that would require lock_sock() there, but the callback can
run in softirq/atomic context, so it must not sleep.&lt;/p&gt;
&lt;p&gt;Make the operation synchronous instead, which removes both the IV race and
any writeback race. This is equivalent to the upstream resolution, commit
fcc77d33a34c (&amp;#34;net: Remove support for AIO on sockets&amp;#34;), which removed the
AIO socket path across net/ entirely and so produces the same end state for
this file. This patch devia…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;crypto: algif_skcipher - force synchronous processing on trees without ctx-&amp;gt;state&lt;/p&gt;
&lt;p&gt;The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx-&amp;gt;iv
directly into the skcipher request. After io_submit() the socket lock is
dropped and the request is processed asynchronously, so a concurrent
sendmsg(ALG_SET_IV) can overwrite ctx-&amp;gt;iv and make the in-flight request
run under an attacker-controlled IV. For CTR/stream modes this is
IV/keystream reuse and lets an unprivileged user recover the plaintext of
a concurrent operation.&lt;/p&gt;
&lt;p&gt;Snapshotting ctx-&amp;gt;iv into per-request storage for the async path is not
sufficient. For ciphers with statesize == 0 - which includes cbc and ctr -
the MSG_MORE inter-chunk IV chaining is carried solely by the in-place
req-&amp;gt;iv writeback, which a snapshot redirects into per-request memory that
af_alg_free_resources() releases on completion, silently producing wrong
output. Writing the IV back from the completion callback instead is not
possible either: that would require lock_sock() there, but the callback can
run in softirq/atomic context, so it must not sleep.&lt;/p&gt;
&lt;p&gt;Make the operation synchronous instead, which removes both the IV race and
any writeback race. This is equivalent to the upstream resolution, commit
fcc77d33a34c (&amp;#34;net: Remove support for AIO on sockets&amp;#34;), which removed the
AIO socket path across net/ entirely and so produces the same end state for
this file. This patch devia…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-74578</guid>
    </item>
  </channel>
</rss>
