https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 18:55:58 +0000 https://vulnerability.circl.lu/vuln/cve-2023-53620 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>md: fix soft lockup in status_resync</p> <p>status_resync() will calculate &#39;curr_resync - recovery_active&#39; to show user a progress bar like following:</p> <p>[============&gt;........] resync = 61.4%</p> <p>&#39;curr_resync&#39; and &#39;recovery_active&#39; is updated in md_do_sync(), and status_resync() can read them concurrently, hence it&#39;s possible that &#39;curr_resync - recovery_active&#39; can overflow to a huge number. In this case status_resync() will be stuck in the loop to print a large amount of &#39;=&#39;, which will end up soft lockup.</p> <p>Fix the problem by setting &#39;resync&#39; to MD_RESYNC_ACTIVE in this case, this way resync in progress will be reported to user.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>md: fix soft lockup in status_resync</p> <p>status_resync() will calculate &#39;curr_resync - recovery_active&#39; to show user a progress bar like following:</p> <p>[============&gt;........] resync = 61.4%</p> <p>&#39;curr_resync&#39; and &#39;recovery_active&#39; is updated in md_do_sync(), and status_resync() can read them concurrently, hence it&#39;s possible that &#39;curr_resync - recovery_active&#39; can overflow to a huge number. In this case status_resync() will be stuck in the loop to print a large amount of &#39;=&#39;, which will end up soft lockup.</p> <p>Fix the problem by setting &#39;resync&#39; to MD_RESYNC_ACTIVE in this case, this way resync in progress will be reported to user.</p> https://vulnerability.circl.lu/vuln/cve-2023-53620