<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T14:02:30.527291+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/cve-2026-90275</id>
    <title>CVE-2026-90275 — md/raid1: don't set array_frozen in raid1_takeover()</title>
    <updated>2026-10-01T14:02:31.873826+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>md/raid1: don't set array_frozen in raid1_takeover()</p>
<p>raid1_takeover() sets conf-&gt;array_frozen = 1 on the newly-allocated
r1conf and nothing ever clears it, so every I/O to the array stalls
permanently once _wait_barrier() sees it stuck at 1.</p>
<p>This used to be harmless: level_store() called mddev_resume() right
after pers-&gt;run(), which called raid1_quiesce(mddev, 0) and cleared
array_frozen back to 0 regardless of what raid1_takeover() set. Commit
b39f35ebe86d ("md: don't quiesce in mddev_suspend()") removed that
quiesce(mddev, 0) call, so the pre-set now sticks.</p>
<p>setup_conf() already zero-initializes the new r1conf via kzalloc, so
just don't set array_frozen here.</p>
<p>Same class of bug as commit 892da88d1cd9 ("md/raid10: fix a
'conf-&gt;barrier' leakage in raid10_takeover()"), also triggered by
b39f35ebe86d.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-90275"/>
  </entry>
</feed>
