https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 00:38:34 +0000 https://vulnerability.circl.lu/vuln/cve-2026-43309 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>md raid: fix hang when stopping arrays with metadata through dm-raid</p> <p>When using device-mapper&#39;s dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.</p> <p>This occurs when:</p> <p>- A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)</p> <p>- The top-level RAID device is then removed</p> <p>Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.</p> <p>Fix:</p> <p>- Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O</p> <p>- Still allow write-intent bitmap flushing when called from dm-raid suspend context</p> <p>This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.</p> <p>This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>md raid: fix hang when stopping arrays with metadata through dm-raid</p> <p>When using device-mapper&#39;s dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.</p> <p>This occurs when:</p> <p>- A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)</p> <p>- The top-level RAID device is then removed</p> <p>Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.</p> <p>Fix:</p> <p>- Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O</p> <p>- Still allow write-intent bitmap flushing when called from dm-raid suspend context</p> <p>This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.</p> <p>This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above.</p> https://vulnerability.circl.lu/vuln/cve-2026-43309