<?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 18:19:30 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-26800 — tls: fix use-after-free on failed backlog decryption</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-26800</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;tls: fix use-after-free on failed backlog decryption&lt;/p&gt;
&lt;p&gt;When the decrypt request goes to the backlog and crypto_aead_decrypt
returns -EBUSY, tls_do_decryption will wait until all async
decryptions have completed. If one of them fails, tls_do_decryption
will return -EBADMSG and tls_decrypt_sg jumps to the error path,
releasing all the pages. But the pages have been passed to the async
callback, and have already been released by tls_decrypt_done.&lt;/p&gt;
&lt;p&gt;The only true async case is when crypto_aead_decrypt returns
 -EINPROGRESS. With -EBUSY, we already waited so we can tell
tls_sw_recvmsg that the data is available for immediate copy, but we
need to notify tls_decrypt_sg (via the new -&amp;gt;async_done flag) that the
memory has already been released.&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;tls: fix use-after-free on failed backlog decryption&lt;/p&gt;
&lt;p&gt;When the decrypt request goes to the backlog and crypto_aead_decrypt
returns -EBUSY, tls_do_decryption will wait until all async
decryptions have completed. If one of them fails, tls_do_decryption
will return -EBADMSG and tls_decrypt_sg jumps to the error path,
releasing all the pages. But the pages have been passed to the async
callback, and have already been released by tls_decrypt_done.&lt;/p&gt;
&lt;p&gt;The only true async case is when crypto_aead_decrypt returns
 -EINPROGRESS. With -EBUSY, we already waited so we can tell
tls_sw_recvmsg that the data is available for immediate copy, but we
need to notify tls_decrypt_sg (via the new -&amp;gt;async_done flag) that the
memory has already been released.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-26800</guid>
    </item>
    <item>
      <title>LSN-0108-1 — Kernel Live Patch Security Notice</title>
      <link>https://vulnerability.circl.lu/vuln/lsn-0108-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:Pro:18.04:LTS: linux-azure-4.15, Ubuntu:Pro:18.04:LTS: linux-gcp-4.15 and 22 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been
resolved: tls: fix use-after-free on failed backlog decryption When the
decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY,
tls_do_decryption will wait until all async decryptions have completed. If
one of them fails, tls_do_decryption will return -EBADMSG and
tls_decrypt_sg jumps to the error path, releasing all the pages. But the
pages have been passed to the async callback, and have already been
released by tls_decrypt_done. The only true async case is when
crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so
we can tell tls_sw_recvmsg that the data is available for immediate copy,
but we need to notify tls_decrypt_sg (via the new -&amp;gt;async_done flag) that
the memory has already been released.)(CVE-2024-26800)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been
resolved: inet: inet_defrag: prevent sk release while still in use
ip_local_out() and other functions can pass skb-&amp;gt;sk as function argument.
If the skb is a fragment and reassembly happens before such function call
returns, the sk must not be released. This affects skb fragments
reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c,
when run as part of tx pipeline. Eric Dumazet made an initial analysis of
this bug. Quoting Eric: Calling ip_defrag() in output path is also implying
skb_orphan(), which is buggy because output path relies on sk not
disappearing. A relevant old patch about t…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:Pro:18.04:LTS: linux-azure-4.15, Ubuntu:Pro:18.04:LTS: linux-gcp-4.15 and 22 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been
resolved: tls: fix use-after-free on failed backlog decryption When the
decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY,
tls_do_decryption will wait until all async decryptions have completed. If
one of them fails, tls_do_decryption will return -EBADMSG and
tls_decrypt_sg jumps to the error path, releasing all the pages. But the
pages have been passed to the async callback, and have already been
released by tls_decrypt_done. The only true async case is when
crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so
we can tell tls_sw_recvmsg that the data is available for immediate copy,
but we need to notify tls_decrypt_sg (via the new -&amp;gt;async_done flag) that
the memory has already been released.)(CVE-2024-26800)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been
resolved: inet: inet_defrag: prevent sk release while still in use
ip_local_out() and other functions can pass skb-&amp;gt;sk as function argument.
If the skb is a fragment and reassembly happens before such function call
returns, the sk must not be released. This affects skb fragments
reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c,
when run as part of tx pipeline. Eric Dumazet made an initial analysis of
this bug. Quoting Eric: Calling ip_defrag() in output path is also implying
skb_orphan(), which is buggy because output path relies on sk not
disappearing. A relevant old patch about t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/lsn-0108-1</guid>
    </item>
  </channel>
</rss>
