CVE-2021-47214
published 2024-04-10CVE-2021-47214: In the Linux kernel, the following vulnerability has been resolved: hugetlb, userfaultfd: fix reservation restore on userfaultfd error Currently in the…
PriorityP417medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.19%
9.3th percentile
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 "goto out_release_unlock;" in the cases where idx >=
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->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.
Affected
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.15.5-1 (bookworm) | linux 5.15.5-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 5.13.13 < 5.14 | 5.14 |
| linux | linux | >= c7b1850dfb41d0b4154aca8dbc04777fbd75616f < b5069d44e2fbc4a9093d005b3ef0949add3dd27e | b5069d44e2fbc4a9093d005b3ef0949add3dd27e |
| linux | linux | >= c7b1850dfb41d0b4154aca8dbc04777fbd75616f < cc30042df6fcc82ea18acf0dace831503e60a0b7 | cc30042df6fcc82ea18acf0dace831503e60a0b7 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.15.5-1 | 5.15.5-1 |
| linux | linux_kernel | >= 0 < 5.15.5-1 | 5.15.5-1 |
| linux | linux_kernel | >= 0 < 5.15.5-1 | 5.15.5-1 |
| linux | linux_kernel | >= 5.14 < 5.15.5 | 5.15.5 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-rr47-vpr9-84rm: In the Linux kernel, the following vulnerability has been resolved:
hugetlb, userfaultfd: fix reservation restore on userfaultfd error
Currently in
ghsa_unreviewed·2024-04-10
CVE-2021-47214 [MEDIUM] CWE-401 GHSA-rr47-vpr9-84rm: In the Linux kernel, the following vulnerability has been resolved:
hugetlb, userfaultfd: fix reservation restore on userfaultfd error
Currently in
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 "goto out_release_unlock;" in the cases where idx >=
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->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
rest
OSV
CVE-2021-47214: In the Linux kernel, the following vulnerability has been resolved: hugetlb, userfaultfd: fix reservation restore on userfaultfd error Currently in th
osv·2024-04-10·CVSS 5.5
CVE-2021-47214 [MEDIUM] CVE-2021-47214: In the Linux kernel, the following vulnerability has been resolved: hugetlb, userfaultfd: fix reservation restore on userfaultfd error Currently in th
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 "goto out_release_unlock;" in the cases where idx >= 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->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
Red Hat
kernel: hugetlb, userfaultfd: fix reservation restore on userfaultfd error
vendor_redhat·2024-04-10·CVSS 5.5
CVE-2021-47214 [MEDIUM] CWE-402 kernel: hugetlb, userfaultfd: fix reservation restore on userfaultfd error
kernel: hugetlb, userfaultfd: fix reservation restore on userfaultfd error
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 "goto out_release_unlock;" in the cases where idx >=
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->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
Debian
CVE-2021-47214: linux - In the Linux kernel, the following vulnerability has been resolved: hugetlb, us...
vendor_debian·2021·CVSS 5.5
CVE-2021-47214 [MEDIUM] CVE-2021-47214: linux - In the Linux kernel, the following vulnerability has been resolved: hugetlb, us...
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 "goto out_release_unlock;" in the cases where idx >= 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->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
No detection rules found.
No public exploits indexed.
2024-04-10
Published