<?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://db.gcve.eu</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>Tue, 03 Nov 2026 20:53:17 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-98745 — arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems</title>
      <link>https://db.gcve.eu/vuln/cve-2026-98745</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;arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems&lt;/p&gt;
&lt;p&gt;When system_supports_sme() is true but system_supports_sve() is false,
restoring a specifically crafted SVE signal context can result in the
task erroneously having non-streaming SVE state. Subsequent attempts to
manipulate the task&amp;#39;s FPSIMD/SVE/SME state can result in a variety of
problems, including fatal EL1 UNDEFs.&lt;/p&gt;
&lt;p&gt;In such configurations, the kernel always creates an SVE signal context
when delivering a signal, and this can only be in one of two states:&lt;/p&gt;
&lt;p&gt;(1) SVE_SIG_FLAG_SM is set, and an SVE payload is present containing
    streaming mode SVE state. The recorded VL is the task&amp;#39;s live
    streaming VL.&lt;/p&gt;
&lt;p&gt;(2) SVE_SIG_FLAG_SM is clear, and an SVE payload is not present. The
    FPSIMD context contains the non-streaming mode FPSIMD state. The
    recorded VL is 0.&lt;/p&gt;
&lt;p&gt;Currently restore_sve_fpsimd_context() correctly rejects cases where
SVE_SIG_FLAG_SM is set and an SVE payload is not present, but fails to
reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is
present. Consequently, restore_sve_fpsimd_context() can place the task
in a state where it has non-streaming SVE state even when this is not
supported by HW.&lt;/p&gt;
&lt;p&gt;For example, this can cause a later EL1 UNDEF when the kernel attempts to
restore the task&amp;#39;s ZCR_EL1 value:&lt;/p&gt;
&lt;p&gt;| # ./sme-sigcontext-to-sve
| Internal error: Oops - Undefined instruction: 0000000002000000 [#1]  SMP…&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;arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems&lt;/p&gt;
&lt;p&gt;When system_supports_sme() is true but system_supports_sve() is false,
restoring a specifically crafted SVE signal context can result in the
task erroneously having non-streaming SVE state. Subsequent attempts to
manipulate the task&amp;#39;s FPSIMD/SVE/SME state can result in a variety of
problems, including fatal EL1 UNDEFs.&lt;/p&gt;
&lt;p&gt;In such configurations, the kernel always creates an SVE signal context
when delivering a signal, and this can only be in one of two states:&lt;/p&gt;
&lt;p&gt;(1) SVE_SIG_FLAG_SM is set, and an SVE payload is present containing
    streaming mode SVE state. The recorded VL is the task&amp;#39;s live
    streaming VL.&lt;/p&gt;
&lt;p&gt;(2) SVE_SIG_FLAG_SM is clear, and an SVE payload is not present. The
    FPSIMD context contains the non-streaming mode FPSIMD state. The
    recorded VL is 0.&lt;/p&gt;
&lt;p&gt;Currently restore_sve_fpsimd_context() correctly rejects cases where
SVE_SIG_FLAG_SM is set and an SVE payload is not present, but fails to
reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is
present. Consequently, restore_sve_fpsimd_context() can place the task
in a state where it has non-streaming SVE state even when this is not
supported by HW.&lt;/p&gt;
&lt;p&gt;For example, this can cause a later EL1 UNDEF when the kernel attempts to
restore the task&amp;#39;s ZCR_EL1 value:&lt;/p&gt;
&lt;p&gt;| # ./sme-sigcontext-to-sve
| Internal error: Oops - Undefined instruction: 0000000002000000 [#1]  SMP…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-98745</guid>
    </item>
  </channel>
</rss>
