https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 15:14:43 +0000 https://vulnerability.circl.lu/vuln/bell-cve-2026-63813 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Withdrawn by the publisher.</strong></p> https://vulnerability.circl.lu/vuln/bell-cve-2026-63813 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1162 certfr-2026-avi-1162 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1162 https://vulnerability.circl.lu/vuln/fkie_cve-2026-63813 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Revert &#34;f2fs: remove non-uptodate folio from the page cache in move_data_block&#34;</p> <p>This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598.</p> <p>The kernel panics are keeping to be reported especially when the f2fs partition get almost full. By investigation, we find that the reason is one f2fs page got freed to buddy without being deleted from LRU and the root cause is the race happened in [2] which is enrolled by this commit.</p> <p>There are 3 race processes in this scenario, please find below for their main activities.</p> <p>The changed code in move_data_block() lets the GC path evict the tail-end folio from the page cache through folio_end_dropbehind(). Once folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the page-cache references for all pages in the folio are dropped. The folio is then kept alive only by temporary external references, which allows a later split to operate on a folio whose subpages are no longer protected by page-cache references.</p> <p>After the page-cache references are gone, split_folio_to_order() can split the big folio into individual pages and put the resulting subpages back on the LRU. For tail pages beyond EOF, split removes them from the page cache and drops their page-cache references. A tail page can then remain on the LRU with PG_lru set while holding only the split caller&#39;s temporary reference. When free_folio_and_swap_cache() drops that final reference, the page en…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Revert &#34;f2fs: remove non-uptodate folio from the page cache in move_data_block&#34;</p> <p>This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598.</p> <p>The kernel panics are keeping to be reported especially when the f2fs partition get almost full. By investigation, we find that the reason is one f2fs page got freed to buddy without being deleted from LRU and the root cause is the race happened in [2] which is enrolled by this commit.</p> <p>There are 3 race processes in this scenario, please find below for their main activities.</p> <p>The changed code in move_data_block() lets the GC path evict the tail-end folio from the page cache through folio_end_dropbehind(). Once folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the page-cache references for all pages in the folio are dropped. The folio is then kept alive only by temporary external references, which allows a later split to operate on a folio whose subpages are no longer protected by page-cache references.</p> <p>After the page-cache references are gone, split_folio_to_order() can split the big folio into individual pages and put the resulting subpages back on the LRU. For tail pages beyond EOF, split removes them from the page cache and drops their page-cache references. A tail page can then remain on the LRU with PG_lru set while holding only the split caller&#39;s temporary reference. When free_folio_and_swap_cache() drops that final reference, the page en…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-63813 https://vulnerability.circl.lu/vuln/ghsa-q48g-gvv8-2599 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Revert &#34;f2fs: remove non-uptodate folio from the page cache in move_data_block&#34;</p> <p>This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598.</p> <p>The kernel panics are keeping to be reported especially when the f2fs partition get almost full. By investigation, we find that the reason is one f2fs page got freed to buddy without being deleted from LRU and the root cause is the race happened in [2] which is enrolled by this commit.</p> <p>There are 3 race processes in this scenario, please find below for their main activities.</p> <p>The changed code in move_data_block() lets the GC path evict the tail-end folio from the page cache through folio_end_dropbehind(). Once folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the page-cache references for all pages in the folio are dropped. The folio is then kept alive only by temporary external references, which allows a later split to operate on a folio whose subpages are no longer protected by page-cache references.</p> <p>After the page-cache references are gone, split_folio_to_order() can split the big folio into individual pages and put the resulting subpages back on the LRU. For tail pages beyond EOF, split removes them from the page cache and drops their page-cache references. A tail page can then remain on the LRU with PG_lru set while holding only the split caller&#39;s temporary reference. When free_folio_and_swap_cache() drops that final reference, the page en…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Revert &#34;f2fs: remove non-uptodate folio from the page cache in move_data_block&#34;</p> <p>This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598.</p> <p>The kernel panics are keeping to be reported especially when the f2fs partition get almost full. By investigation, we find that the reason is one f2fs page got freed to buddy without being deleted from LRU and the root cause is the race happened in [2] which is enrolled by this commit.</p> <p>There are 3 race processes in this scenario, please find below for their main activities.</p> <p>The changed code in move_data_block() lets the GC path evict the tail-end folio from the page cache through folio_end_dropbehind(). Once folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the page-cache references for all pages in the folio are dropped. The folio is then kept alive only by temporary external references, which allows a later split to operate on a folio whose subpages are no longer protected by page-cache references.</p> <p>After the page-cache references are gone, split_folio_to_order() can split the big folio into individual pages and put the resulting subpages back on the LRU. For tail pages beyond EOF, split removes them from the page cache and drops their page-cache references. A tail page can then remain on the LRU with PG_lru set while holding only the split caller&#39;s temporary reference. When free_folio_and_swap_cache() drops that final reference, the page en…</p> https://vulnerability.circl.lu/vuln/ghsa-q48g-gvv8-2599 https://vulnerability.circl.lu/vuln/opensuse-su-2026:11339-1 <p>kernel-devel-7.1.4-1.1 on GA media</p> <p>kernel-devel-7.1.4-1.1 on GA media</p> https://vulnerability.circl.lu/vuln/opensuse-su-2026:11339-1 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-63813 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 112 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: Revert &#34;f2fs: remove non-uptodate folio from the page cache in move_data_block&#34; This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598. The kernel panics are keeping to be reported especially when the f2fs partition get almost full. By investigation, we find that the reason is one f2fs page got freed to buddy without being deleted from LRU and the root cause is the race happened in [2] which is enrolled by this commit. There are 3 race processes in this scenario, please find below for their main activities. The changed code in move_data_block() lets the GC path evict the tail-end folio from the page cache through folio_end_dropbehind(). Once folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the page-cache references for all pages in the folio are dropped. The folio is then kept alive only by temporary external references, which allows a later split to operate on a folio whose subpages are no longer protected by page-cache references. After the page-cache references are gone, split_folio_to_order() can split the big folio into individual pages and put the resulting subpages back on the LRU. For tail pages beyond EOF, split removes them from the page cache and drops their page-cache references. A tail page can then remain on the LRU with PG_lru set while holding only the split caller&#39;s temporary reference. When free_folio_and_swap_cache() drops that final reference, the page enters t…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 112 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: Revert &#34;f2fs: remove non-uptodate folio from the page cache in move_data_block&#34; This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598. The kernel panics are keeping to be reported especially when the f2fs partition get almost full. By investigation, we find that the reason is one f2fs page got freed to buddy without being deleted from LRU and the root cause is the race happened in [2] which is enrolled by this commit. There are 3 race processes in this scenario, please find below for their main activities. The changed code in move_data_block() lets the GC path evict the tail-end folio from the page cache through folio_end_dropbehind(). Once folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the page-cache references for all pages in the folio are dropped. The folio is then kept alive only by temporary external references, which allows a later split to operate on a folio whose subpages are no longer protected by page-cache references. After the page-cache references are gone, split_folio_to_order() can split the big folio into individual pages and put the resulting subpages back on the LRU. For tail pages beyond EOF, split removes them from the page cache and drops their page-cache references. A tail page can then remain on the LRU with PG_lru set while holding only the split caller&#39;s temporary reference. When free_folio_and_swap_cache() drops that final reference, the page enters t…</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-63813 https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2403 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.</p> https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2403