https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 13:32:32 +0000 https://vulnerability.circl.lu/vuln/bell-cve-2026-64514 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://vulnerability.circl.lu/vuln/bell-cve-2026-64514 https://vulnerability.circl.lu/vuln/certfr-2026-avi-0982 certfr-2026-avi-0982 https://vulnerability.circl.lu/vuln/certfr-2026-avi-0982 https://vulnerability.circl.lu/vuln/fkie_cve-2026-64514 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>userfaultfd: gate must_wait writability check on pte_present()</p> <p>userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result.</p> <p>The intent of the check is &#34;is this fault still WP-blocked?&#34;. A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says &#34;wait&#34;, and the thread stays asleep until a UFFDIO_WAKE that may never arrive.</p> <p>Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns &#34;don&#39;t wait&#34; and lets the fault path retry.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>userfaultfd: gate must_wait writability check on pte_present()</p> <p>userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result.</p> <p>The intent of the check is &#34;is this fault still WP-blocked?&#34;. A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says &#34;wait&#34;, and the thread stays asleep until a UFFDIO_WAKE that may never arrive.</p> <p>Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns &#34;don&#39;t wait&#34; and lets the fault path retry.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-64514 https://vulnerability.circl.lu/vuln/ghsa-r2gx-xm5r-33f5 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>userfaultfd: gate must_wait writability check on pte_present()</p> <p>userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result.</p> <p>The intent of the check is &#34;is this fault still WP-blocked?&#34;. A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says &#34;wait&#34;, and the thread stays asleep until a UFFDIO_WAKE that may never arrive.</p> <p>Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns &#34;don&#39;t wait&#34; and lets the fault path retry.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>userfaultfd: gate must_wait writability check on pte_present()</p> <p>userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result.</p> <p>The intent of the check is &#34;is this fault still WP-blocked?&#34;. A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says &#34;wait&#34;, and the thread stays asleep until a UFFDIO_WAKE that may never arrive.</p> <p>Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns &#34;don&#39;t wait&#34; and lets the fault path retry.</p> https://vulnerability.circl.lu/vuln/ghsa-r2gx-xm5r-33f5 https://vulnerability.circl.lu/vuln/msrc_cve-2026-64514 msrc_CVE-2026-64514 https://vulnerability.circl.lu/vuln/msrc_cve-2026-64514 https://vulnerability.circl.lu/vuln/opensuse-su-2026:11476-1 <p>kernel-devel-7.1.7-1.1 on GA media</p> <p>kernel-devel-7.1.7-1.1 on GA media</p> https://vulnerability.circl.lu/vuln/opensuse-su-2026:11476-1 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-64514 <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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is &#34;is this fault still WP-blocked?&#34;. A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says &#34;wait&#34;, and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns &#34;don&#39;t wait&#34; and lets the fault path retry.</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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is &#34;is this fault still WP-blocked?&#34;. A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says &#34;wait&#34;, and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns &#34;don&#39;t wait&#34; and lets the fault path retry.</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-64514 https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2527 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, dazu können DoS-Angriffe, die Offenlegung von Informationen, die Beschädigung des Speichers oder die Umgehung von Sicherheitsmaßnahmen gehören.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, dazu können DoS-Angriffe, die Offenlegung von Informationen, die Beschädigung des Speichers oder die Umgehung von Sicherheitsmaßnahmen gehören.</p> https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2527