CVE-2024-50220
MediumIn the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series "fork: do not expose incomplete mm on fork". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.
CVSS 3.1 score
4.7
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness type
CWE-367CVE-2024-50220 is classified as CWE-367
See CWE-367 on MITRE CWE for full details on this weakness type.
Affected versions
Linux kernel versions
6.8
and later are affected. Fixed in
6.11.7,
6.12
and their respective stable series.
References
The following references provide additional information about CVE-2024-50220 including vendor advisories, patch commits, exploit details, and third-party analysis. Links are sourced from the NIST NVD database.
-
Third Party Advisory
-
PatchKernel patch commithttps://git.kernel.org/stable/c/92b472945dbf8abc020e9259c0088026f7027dfc
-
PatchKernel patch commithttps://git.kernel.org/stable/c/f64e67e5d3a45a4a04286c47afade4b518acd47b
Frequently asked questions
-
What is CVE-2024-50220?
CVE-2024-50220 is a Medium severity Linux kernel vulnerability with a CVSS score of 4.7 out of 10 . It affects Linux kernel versions from 6.8 onward and has been patched in 6.11.7 and 6.12. CVE-2024-50220 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.
-
What is the CVSS score for CVE-2024-50220?
CVE-2024-50220 has a CVSS score of 4.7 out of 10, rated Medium severity (CVSS 3.1). The vector string is
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H. -
Is there a patch available for CVE-2024-50220?
Yes — CVE-2024-50220 has been patched. Fixed versions include 6.11.7 and 6.12. If you are running Linux kernel 6.8 or later up to the fix versions, apply the relevant patch for your kernel branch.
-
Is CVE-2024-50220 actively exploited?
No — CVE-2024-50220 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.