<?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>Thu, 01 Oct 2026 05:16:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-46249 — octeontx2-af: Fix PF driver crash with kexec kernel booting</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-46249</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;octeontx2-af: Fix PF driver crash with kexec kernel booting&lt;/p&gt;
&lt;p&gt;During a kexec reboot the hardware is not power-cycled, so AF state from
the old kernel can persist into the new kernel. When AF and PF drivers
are built as modules, the PF driver may probe before AF reinitializes
the hardware.&lt;/p&gt;
&lt;p&gt;The PF driver treats the RVUM block revision as an indication that AF
initialization is complete. If this value is left uncleared at shutdown,
PF may incorrectly assume AF is ready and access stale hardware state,
leading to a crash.&lt;/p&gt;
&lt;p&gt;Clear the RVUM block revision during AF shutdown to avoid PF
mis-detecting AF readiness after kexec.&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;octeontx2-af: Fix PF driver crash with kexec kernel booting&lt;/p&gt;
&lt;p&gt;During a kexec reboot the hardware is not power-cycled, so AF state from
the old kernel can persist into the new kernel. When AF and PF drivers
are built as modules, the PF driver may probe before AF reinitializes
the hardware.&lt;/p&gt;
&lt;p&gt;The PF driver treats the RVUM block revision as an indication that AF
initialization is complete. If this value is left uncleared at shutdown,
PF may incorrectly assume AF is ready and access stale hardware state,
leading to a crash.&lt;/p&gt;
&lt;p&gt;Clear the RVUM block revision during AF shutdown to avoid PF
mis-detecting AF readiness after kexec.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-46249</guid>
    </item>
  </channel>
</rss>
