https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-10-01T14:48:34.290137+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/CERTFR-2025-AVI-1057 CERTFR-2025-AVI-1057 — De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer… 2026-10-01T14:48:34.301844+00:00 CERTFR-2025-AVI-1057 https://vulnerability.circl.lu/vuln/bdu:2026-04021 bdu:2026-04021 2026-10-01T14:48:34.301926+00:00 bdu:2026-04021 https://vulnerability.circl.lu/vuln/fkie_cve-2022-49554 fkie_cve-2022-49554 2026-10-01T14:48:34.301944+00:00

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's entire page list without defending against page migration. Since pages which haven'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's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage'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.

 https://vulnerability.circl.lu/vuln/ghsa-wv76-pjmf-rxjc GHSA-wv76-pjmf-rxjc 2026-10-01T14:48:34.302000+00:00

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's entire page list without defending against page migration. Since pages which haven'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's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage'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.

 https://vulnerability.circl.lu/vuln/ubuntu-cve-2022-49554 UBUNTU-CVE-2022-49554 2026-10-01T14:48:34.302032+00:00

Affected: 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

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's entire page list without defending against page migration. Since pages which haven'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's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage'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.