https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 14:48:33 +0000 https://vulnerability.circl.lu/vuln/CERTFR-2025-AVI-1057 CERTFR-2025-AVI-1057 https://vulnerability.circl.lu/vuln/CERTFR-2025-AVI-1057 https://vulnerability.circl.lu/vuln/bdu:2026-04021 bdu:2026-04021 https://vulnerability.circl.lu/vuln/bdu:2026-04021 https://vulnerability.circl.lu/vuln/fkie_cve-2022-49554 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>zsmalloc: fix races between asynchronous zspage free and page migration</p> <p>The asynchronous zspage free worker tries to lock a zspage&#39;s entire page list without defending against page migration. Since pages which haven&#39;t yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races.</p> <p>It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there&#39;s a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage&#39;s pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process).</p> <p>Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>zsmalloc: fix races between asynchronous zspage free and page migration</p> <p>The asynchronous zspage free worker tries to lock a zspage&#39;s entire page list without defending against page migration. Since pages which haven&#39;t yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races.</p> <p>It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there&#39;s a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage&#39;s pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process).</p> <p>Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2022-49554 https://vulnerability.circl.lu/vuln/ghsa-wv76-pjmf-rxjc <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>zsmalloc: fix races between asynchronous zspage free and page migration</p> <p>The asynchronous zspage free worker tries to lock a zspage&#39;s entire page list without defending against page migration. Since pages which haven&#39;t yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races.</p> <p>It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there&#39;s a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage&#39;s pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process).</p> <p>Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>zsmalloc: fix races between asynchronous zspage free and page migration</p> <p>The asynchronous zspage free worker tries to lock a zspage&#39;s entire page list without defending against page migration. Since pages which haven&#39;t yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races.</p> <p>It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there&#39;s a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage&#39;s pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process).</p> <p>Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.</p> https://vulnerability.circl.lu/vuln/ghsa-wv76-pjmf-rxjc https://vulnerability.circl.lu/vuln/ubuntu-cve-2022-49554 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux, Ubuntu:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.4 and 136 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: zsmalloc: fix races between asynchronous zspage free and page migration The asynchronous zspage free worker tries to lock a zspage&#39;s entire page list without defending against page migration. Since pages which haven&#39;t yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there&#39;s a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage&#39;s pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process). Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux, Ubuntu:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.4 and 136 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: zsmalloc: fix races between asynchronous zspage free and page migration The asynchronous zspage free worker tries to lock a zspage&#39;s entire page list without defending against page migration. Since pages which haven&#39;t yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there&#39;s a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage&#39;s pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process). Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration.</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2022-49554