Skip to main content

CVE-2024-46787: Vulnerability in Linux Linux

High
VulnerabilityCVE-2024-46787cvecve-2024-46787
Published: Wed Sep 18 2024 (09/18/2024, 07:12:43 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following race can occur: mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap PMD> <bail if pmd_trans_huge(*dst_pmd)> BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.

AI-Powered Analysis

AILast updated: 06/29/2025, 01:54:29 UTC

Technical Analysis

CVE-2024-46787 is a vulnerability in the Linux kernel's userfaultfd subsystem, specifically related to race conditions and incorrect checks involving huge Page Middle Directories (PMDs) in memory management. The vulnerability arises from improper handling and verification of huge PMDs in the mfill_atomic() function, which is responsible for filling page tables atomically. The core issue is that the pmd_trans_huge() function, used to detect huge PMDs, is insufficient and racy, leading to three main problems depending on the kernel version: 1) On older kernels (before 6.5), race conditions can cause kernel BUG_ON() triggers or, worse, allow the kernel to treat huge pages as page tables, potentially leading to memory corruption or crashes. 2) The pmd_trans_huge() check does not detect certain PMDs such as device-mapped or migration PMDs, which can cause the kernel to incorrectly assume a PMD points to a page table. This can lead to attempts to lock or write to invalid memory structures, causing kernel oops or crashes. 3) On newer kernels (6.5 and later), the khugepaged subsystem may remove page tables under certain shmem mappings, making the existing BUG_ON() checks invalid. The patch fixes these issues by removing redundant checks and implementing more robust verification to prevent races and incorrect assumptions about PMD types. The vulnerability is complex, involving subtle race conditions in kernel memory management, and has been experimentally verified to cause kernel panics or oops under certain conditions. While no known exploits are currently reported in the wild, the potential for denial of service or system instability is significant if exploited.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running affected Linux kernel versions, especially those using userfaultfd for memory management tasks such as virtualization, containerization, or advanced memory handling. Exploitation could lead to kernel crashes (denial of service), system instability, or potentially memory corruption, which might be leveraged for privilege escalation or other attacks in complex scenarios. Critical infrastructure, cloud service providers, and enterprises relying on Linux-based servers or embedded systems could face operational disruptions. Given the widespread use of Linux in European data centers, telecom infrastructure, and government systems, the impact could be broad. Additionally, industries with high availability requirements (finance, healthcare, manufacturing) could experience significant downtime or data integrity issues if systems are affected. The lack of known exploits reduces immediate risk, but the complexity and subtlety of the bug mean that skilled attackers or malware could develop exploits, especially targeting older kernel versions prevalent in some environments.

Mitigation Recommendations

Organizations should promptly identify and update Linux systems to kernel versions that include the patches addressing CVE-2024-46787. Specifically, kernels version 6.5 and later have fixes for the newer issues, while backported patches are available for older stable kernels (<=6.4). System administrators should audit usage of userfaultfd and related memory management features, particularly in virtualization or container environments, to assess exposure. Applying kernel live patching where available can reduce downtime. Additionally, monitoring kernel logs for BUG_ON() or oops messages related to PMD handling can help detect attempts to trigger the vulnerability. For environments where immediate patching is not feasible, restricting untrusted user access and limiting the use of userfaultfd interfaces can reduce attack surface. Finally, maintaining robust backup and recovery procedures is critical to mitigate potential data loss from crashes.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-09-11T15:12:18.278Z
Cisa Enriched
true
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9827c4522896dcbe12ea

Added to database: 5/21/2025, 9:08:55 AM

Last enriched: 6/29/2025, 1:54:29 AM

Last updated: 8/15/2025, 2:54:37 PM

Views: 16

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats