Linux: Concurrent Execution using Shared Resource with Improper Synchronization
CVE-2024-50066 is a high-severity concurrent execution using shared resource with improper synchronization vulnerability in Linux, with a CVSS 3.1 base score of 7.0 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 17396e32f975130b3e6251f024c8807d192e4c3e, 1552ce9ce8af47c0fe911682e5e1855e25851ca9, 6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.21% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 17396e32f975130b3e6251f024c8807d192e4c3e or 1552ce9ce8af47c0fe911682e5e1855e25851ca9 or 6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa, whichever matches your release line, or a later version.
- Update linux_kernel to 6.6.58 or 17396e32f975 or 1552ce9ce8af or 6fa1066fc5d0, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 1d65b771bc08cd054cf6d3766a72e113dc46d62f up to, but not including, 17396e32f975130b3e6251f024c8807d192e4c3e; 1d65b771bc08cd054cf6d3766a72e113dc46d62f up to, but not including, 1552ce9ce8af47c0fe911682e5e1855e25851ca9; 1d65b771bc08cd054cf6d3766a72e113dc46d62f up to, but not including, 6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa; 6.6 | 17396e32f975130b3e6251f024c8807d192e4c3e, 1552ce9ce8af47c0fe911682e5e1855e25851ca9, 6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa |
| Linux | linux_kernel | 6.6 up to, but not including, 6.6.58; 1d65b771bc08 up to, but not including, 17396e32f975; 1d65b771bc08 up to, but not including, 1552ce9ce8af; 1d65b771bc08 up to, but not including, 6fa1066fc5d0 | 6.6.58, 17396e32f975, 1552ce9ce8af, 6fa1066fc5d0 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- HighSuccess depends on conditions outside the attacker's control.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by NVD.
| Scoring system | Score | Severity | Scored by |
|---|---|---|---|
| CVSS 3.1 | 7.8 | High | CNA |
| CVSS 3.1 | 7.0 | High | NVD |
| CVSS 3.1 | 7.0 | High | CISA (ADP) |
Official description
In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Concurrent Execution using Shared Resource with Improper Synchronization
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
How developers prevent this class of flaw
- In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
- Use thread-safe capabilities such as the data access abstraction in Spring.
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: poc, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other references
Recent Concurrent Execution using Shared Resource with Improper Synchronization vulnerabilities
- 7.0 High severity
- 7.0 High severity
- 7.0 High severity
- 8.1 High severity
- 8.2 High severity
- 7.9 High severity
Spotted an error? Tell us.