https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 23:53:16 +0000 https://cve.radiocsirt.org/vuln/bdu:2024-09137 bdu:2024-09137 https://cve.radiocsirt.org/vuln/bdu:2024-09137 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0420 certfr-2024-avi-0420 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0420 https://cve.radiocsirt.org/vuln/euvd-2026-320218 EUVD-2026-320218 https://cve.radiocsirt.org/vuln/euvd-2026-320218 https://cve.radiocsirt.org/vuln/fkie_cve-2021-47214 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>hugetlb, userfaultfd: fix reservation restore on userfaultfd error</p> <p>Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using &#34;goto out_release_unlock;&#34; in the cases where idx &gt;= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h-&gt;resv_hugepages causing a 100% reproducible leak.</p> <p>We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>hugetlb, userfaultfd: fix reservation restore on userfaultfd error</p> <p>Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using &#34;goto out_release_unlock;&#34; in the cases where idx &gt;= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h-&gt;resv_hugepages causing a 100% reproducible leak.</p> <p>We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2021-47214 https://cve.radiocsirt.org/vuln/ghsa-rr47-vpr9-84rm <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>hugetlb, userfaultfd: fix reservation restore on userfaultfd error</p> <p>Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using &#34;goto out_release_unlock;&#34; in the cases where idx &gt;= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h-&gt;resv_hugepages causing a 100% reproducible leak.</p> <p>We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>hugetlb, userfaultfd: fix reservation restore on userfaultfd error</p> <p>Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using &#34;goto out_release_unlock;&#34; in the cases where idx &gt;= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h-&gt;resv_hugepages causing a 100% reproducible leak.</p> <p>We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear.</p> https://cve.radiocsirt.org/vuln/ghsa-rr47-vpr9-84rm https://cve.radiocsirt.org/vuln/gsd-2021-47214 gsd-2021-47214 https://cve.radiocsirt.org/vuln/gsd-2021-47214 https://cve.radiocsirt.org/vuln/suse-su-2024:1644-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2024:1644-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47214 <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 54 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: hugetlb, userfaultfd: fix reservation restore on userfaultfd error Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using &#34;goto out_release_unlock;&#34; in the cases where idx &gt;= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h-&gt;resv_hugepages causing a 100% reproducible leak. We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear.</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 54 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: hugetlb, userfaultfd: fix reservation restore on userfaultfd error Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using &#34;goto out_release_unlock;&#34; in the cases where idx &gt;= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h-&gt;resv_hugepages causing a 100% reproducible leak. We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47214 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0851 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder unbekannte Auswirkungen zu verursachen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder unbekannte Auswirkungen zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0851