https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 04:52:08 +0000 https://vulnerability.circl.lu/vuln/cve-2026-23157 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: do not strictly require dirty metadata threshold for metadata writepages</p> <p>[BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump.</p> <p>The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18.</p> <p>[CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first.</p> <p>This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB.</p> <p>Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there&#39;s dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying.</p> <p>When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit.</p> <p>So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in th…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: do not strictly require dirty metadata threshold for metadata writepages</p> <p>[BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump.</p> <p>The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18.</p> <p>[CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first.</p> <p>This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB.</p> <p>Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there&#39;s dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying.</p> <p>When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit.</p> <p>So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in th…</p> https://vulnerability.circl.lu/vuln/cve-2026-23157