CVE-2021-46988
published 2024-02-28CVE-2021-46988: In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following sequence of…
PriorityP417medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.24%
15.2th percentile
In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: release page in error path to avoid BUG_ON
Consider the following sequence of events:
1. Userspace issues a UFFD ioctl, which ends up calling into
shmem_mfill_atomic_pte(). We successfully account the blocks, we
shmem_alloc_page(), but then the copy_from_user() fails. We return
-ENOENT. We don't release the page we allocated.
2. Our caller detects this error code, tries the copy_from_user() after
dropping the mmap_lock, and retries, calling back into
shmem_mfill_atomic_pte().
3. Meanwhile, let's say another process filled up the tmpfs being used.
4. So shmem_mfill_atomic_pte() fails to account blocks this time, and
immediately returns - without releasing the page.
This triggers a BUG_ON in our caller, which asserts that the page
should always be consumed, unless -ENOENT is returned.
To fix this, detect if we have such a "dangling" page when accounting
fails, and if so, release it before returning.
Affected
20 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.10.38-1 (bookworm) | linux 5.10.38-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= cb658a453b9327ce96ce5222c24d162b5b65b564 < 319116227e52d49eee671f0aa278bac89b3c1b69 | 319116227e52d49eee671f0aa278bac89b3c1b69 |
| linux | linux | >= cb658a453b9327ce96ce5222c24d162b5b65b564 < 07c9b834c97d0fa3402fb7f3f3b32df370a6ff1f | 07c9b834c97d0fa3402fb7f3f3b32df370a6ff1f |
| linux | linux | >= cb658a453b9327ce96ce5222c24d162b5b65b564 < b3f1731c6d7fbc1ebe3ed8eff6d6bec56d76ff43 | b3f1731c6d7fbc1ebe3ed8eff6d6bec56d76ff43 |
| linux | linux | >= cb658a453b9327ce96ce5222c24d162b5b65b564 < 140cfd9980124aecb6c03ef2e69c72d0548744de | 140cfd9980124aecb6c03ef2e69c72d0548744de |
| linux | linux | >= cb658a453b9327ce96ce5222c24d162b5b65b564 < ad53127973034c63b5348715a1043d0e80ceb330 | ad53127973034c63b5348715a1043d0e80ceb330 |
| linux | linux | >= cb658a453b9327ce96ce5222c24d162b5b65b564 < 2d59a0ed8b26b8f3638d8afc31f839e27759f1f6 | 2d59a0ed8b26b8f3638d8afc31f839e27759f1f6 |
| linux | linux | >= cb658a453b9327ce96ce5222c24d162b5b65b564 < 7ed9d238c7dbb1fdb63ad96a6184985151b0171c | 7ed9d238c7dbb1fdb63ad96a6184985151b0171c |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.38-1 | 5.10.38-1 |
| linux | linux_kernel | >= 0 < 5.10.38-1 | 5.10.38-1 |
| linux | linux_kernel | >= 0 < 5.10.38-1 | 5.10.38-1 |
| linux | linux_kernel | >= 0 < 5.10.38-1 | 5.10.38-1 |
| linux | linux_kernel | >= 4.11 < 4.14.233 | 4.14.233 |
| linux | linux_kernel | >= 4.15 < 4.19.191 | 4.19.191 |
| linux | linux_kernel | >= 4.20 < 5.4.120 | 5.4.120 |
| linux | linux_kernel | >= 5.11 < 5.11.22 | 5.11.22 |
| linux | linux_kernel | >= 5.12 < 5.12.5 | 5.12.5 |
| linux | linux_kernel | >= 5.5 < 5.10.38 | 5.10.38 |
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.
Red Hat
kernel: userfaultfd: release page in error path to avoid BUG_ON
vendor_redhat·2024-02-28·CVSS 5.5
CVE-2021-46988 [MEDIUM] CWE-416 kernel: userfaultfd: release page in error path to avoid BUG_ON
kernel: userfaultfd: release page in error path to avoid BUG_ON
In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: release page in error path to avoid BUG_ON
Consider the following sequence of events:
1. Userspace issues a UFFD ioctl, which ends up calling into
shmem_mfill_atomic_pte(). We successfully account the blocks, we
shmem_alloc_page(), but then the copy_from_user() fails. We return
-ENOENT. We don't release the page we allocated.
2. Our caller detects this error code, tries the copy_from_user() after
dropping the mmap_lock, and retries, calling back into
shmem_mfill_atomic_pte().
3. Meanwhile, let's say another process filled up the tmpfs being used.
4. So shmem_mfill_atomic_pte() fails to account blocks this time, and
immediately returns - without r
Debian
CVE-2021-46988: linux - In the Linux kernel, the following vulnerability has been resolved: userfaultfd...
vendor_debian·2021·CVSS 5.5
CVE-2021-46988 [MEDIUM] CVE-2021-46988: linux - In the Linux kernel, the following vulnerability has been resolved: userfaultfd...
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page. This triggers a BUG_ON in our caller, which as
OSV
CVE-2021-46988: In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following seq
osv·2024-02-28·CVSS 5.5
CVE-2021-46988 [MEDIUM] CVE-2021-46988: In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following seq
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page. This triggers a BUG_ON in our caller, which as
GHSA
GHSA-w36p-947m-7c32: In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: release page in error path to avoid BUG_ON
Consider the following s
ghsa_unreviewed·2024-02-28
CVE-2021-46988 [MEDIUM] CWE-416 GHSA-w36p-947m-7c32: In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: release page in error path to avoid BUG_ON
Consider the following s
In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: release page in error path to avoid BUG_ON
Consider the following sequence of events:
1. Userspace issues a UFFD ioctl, which ends up calling into
shmem_mfill_atomic_pte(). We successfully account the blocks, we
shmem_alloc_page(), but then the copy_from_user() fails. We return
-ENOENT. We don't release the page we allocated.
2. Our caller detects this error code, tries the copy_from_user() after
dropping the mmap_lock, and retries, calling back into
shmem_mfill_atomic_pte().
3. Meanwhile, let's say another process filled up the tmpfs being used.
4. So shmem_mfill_atomic_pte() fails to account blocks this time, and
immediately returns - without releasing the page.
This triggers a BUG_ON in our caller, whic
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/07c9b834c97d0fa3402fb7f3f3b32df370a6ff1fhttps://git.kernel.org/stable/c/140cfd9980124aecb6c03ef2e69c72d0548744dehttps://git.kernel.org/stable/c/2d59a0ed8b26b8f3638d8afc31f839e27759f1f6https://git.kernel.org/stable/c/319116227e52d49eee671f0aa278bac89b3c1b69https://git.kernel.org/stable/c/7ed9d238c7dbb1fdb63ad96a6184985151b0171chttps://git.kernel.org/stable/c/ad53127973034c63b5348715a1043d0e80ceb330https://git.kernel.org/stable/c/b3f1731c6d7fbc1ebe3ed8eff6d6bec56d76ff43https://git.kernel.org/stable/c/07c9b834c97d0fa3402fb7f3f3b32df370a6ff1fhttps://git.kernel.org/stable/c/140cfd9980124aecb6c03ef2e69c72d0548744dehttps://git.kernel.org/stable/c/2d59a0ed8b26b8f3638d8afc31f839e27759f1f6https://git.kernel.org/stable/c/319116227e52d49eee671f0aa278bac89b3c1b69https://git.kernel.org/stable/c/7ed9d238c7dbb1fdb63ad96a6184985151b0171chttps://git.kernel.org/stable/c/ad53127973034c63b5348715a1043d0e80ceb330https://git.kernel.org/stable/c/b3f1731c6d7fbc1ebe3ed8eff6d6bec56d76ff43
2024-02-28
Published