https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 15:25:29 +0000 https://vulnerability.circl.lu/vuln/cve-2026-72155 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mtd: spi-nor: swp: Improve locking user experience</p> <p>In the case of the first block being locked (or the few first blocks), if the user want to fully unlock the device it has two possibilities: - either it asks to unlock the entire device, and this works; - or it asks to unlock just the block(s) that are currently locked, which fails.</p> <p>It fails because the conditions &#34;can_be_top&#34; and &#34;can_be_bottom&#34; are true. Indeed, in this case, we unlock everything, so the TB bit does not matter. However in the current implementation, use_top would be true (as this is the favourite option) and lock_len, which in practice should be reduced down to 0, is set to &#34;nor-&gt;params-&gt;size - (ofs + len)&#34; which is a positive number. This is wrong.</p> <p>An easy way is to simply add an extra condition. In the unlock() path, if we can achieve the same result from both sides, it means we unlock everything and lock_len must simply be 0. A comment is added to clarify that logic.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mtd: spi-nor: swp: Improve locking user experience</p> <p>In the case of the first block being locked (or the few first blocks), if the user want to fully unlock the device it has two possibilities: - either it asks to unlock the entire device, and this works; - or it asks to unlock just the block(s) that are currently locked, which fails.</p> <p>It fails because the conditions &#34;can_be_top&#34; and &#34;can_be_bottom&#34; are true. Indeed, in this case, we unlock everything, so the TB bit does not matter. However in the current implementation, use_top would be true (as this is the favourite option) and lock_len, which in practice should be reduced down to 0, is set to &#34;nor-&gt;params-&gt;size - (ofs + len)&#34; which is a positive number. This is wrong.</p> <p>An easy way is to simply add an extra condition. In the unlock() path, if we can achieve the same result from both sides, it means we unlock everything and lock_len must simply be 0. A comment is added to clarify that logic.</p> https://vulnerability.circl.lu/vuln/cve-2026-72155