https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 05 Nov 2026 19:01:12 +0000 https://db.gcve.eu/vuln/cve-2026-99256 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache: fix issue with background work locking</p> <p>dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device &lt;cache&gt;, run: &#39;dmsetup suspend &lt;cache&gt; &amp;&amp; dmsetup resume &lt;cache&gt;&#39;. This will trigger a kernel warning:</p> <p>DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &amp;&amp; !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE))</p> <p>triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn&#39;t actually used by anything. This is replaced by the background_work queue and counter.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache: fix issue with background work locking</p> <p>dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device &lt;cache&gt;, run: &#39;dmsetup suspend &lt;cache&gt; &amp;&amp; dmsetup resume &lt;cache&gt;&#39;. This will trigger a kernel warning:</p> <p>DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &amp;&amp; !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE))</p> <p>triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn&#39;t actually used by anything. This is replaced by the background_work queue and counter.</p> https://db.gcve.eu/vuln/cve-2026-99256