CVE-2024-36881: mm/userfaultfd: reset ptes when close() for wr-protected ones
In the Linux kernel, the following vulnerability has been resolved:
mm/userfaultfd: reset ptes when close() for wr-protected ones
Userfaultfd unregister includes a step to remove wr-protect bits from all
the relevant pgtable entries, but that only covered an explicit
UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover
that too. This fixes a WARN trace.
The only user visible side effect is the user can observe leftover
wr-protect bits even if the user close()ed on an userfaultfd when
releasing the last reference of it. However hopefully that should be
harmless, and nothing bad should happen even if so.
This change is now more important after the recent page-table-check
patch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check:
support userfault wr-protect entries")), as we'll do sanity check on
uffd-wp bits without vma context. So it's better if we can 100%
guarantee no uffd-wp bit leftovers, to make sure each report will be
valid.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel availability bug in userfaultfd cleanup. When a process closes a userfaultfd, write-protect markers can remain in page-table entries. The source describes the visible effect as leftover bits that are hopefully harmless, but the CVSS score rates availability impact as high for a local, low-privilege attacker.
Executive priority
Treat as a routine but real kernel maintenance item. It is not a remote takeover issue based on the supplied evidence, but it can affect availability and should be included in normal kernel patch cycles, with faster handling for shared or untrusted-workload systems.
Technical view
The fix resets userfaultfd write-protect PTE state during close(), matching cleanup already done by explicit UFFDIO_UNREGISTER. Without this, stale uffd-wp bits can remain after the last userfaultfd reference is released, causing warning or sanity-check failures after page-table-check support for userfault write-protect entries.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions or downstream builds without the stable fix. The CVE record lists local attack vector and low privileges, so remotely exposed services are not directly implicated by the supplied sources.
Exploitation context
The supplied sources do not report active exploitation, and CISA KEV status is false. The issue requires local access and relates to kernel memory-management state cleanup. No public exploit status or weaponized technique is supported by the provided bundle.
Researcher notes
Key evidence is the kernel fix description and CVSS vector. The impact appears centered on stale uffd-wp PTE bits after close(), with availability risk. The source text itself downplays user-visible impact, so avoid overstating exploitability without additional vendor or exploit intelligence.
Mitigation direction
Update to a vendor kernel containing the referenced stable fixes.
Prioritize multi-user, container-host, and untrusted-workload Linux systems.
Check distribution advisories for backported CVE-2024-36881 fixes.
Reduce untrusted local code execution until kernel updates are applied.
Follow Linux kernel and distribution guidance for userfaultfd hardening.
Validation and detection
Inventory Linux kernel versions across servers, workstations, and container hosts.
Confirm whether vendor packages include CVE-2024-36881 or the stable commits.
Check kernel changelogs for userfaultfd close() write-protect cleanup.
Review exposure where untrusted users or workloads can run local code.
Track remediation status separately for upstream and distribution-backported kernels.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-36881 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.