CVE-2024-50066 is a race condition vulnerability in the Linux kernel's memory management subsystem, specifically within the mremap() function that handles remapping of virtual memory areas. The vulnerability arises in the handling of huge page mappings (Transparent Huge Pages, THP) backed by tmpfs files. The core issue is a race between two processes manipulating page tables: process A performing mremap() and process B performing madvise(MADV_COLLAPSE) on the same tmpfs-backed huge page mappings. During mremap(), the kernel holds the mmap_lock in write mode but does not yet hold reverse mapping (rmap) locks when it reads the Page Middle Directory (PMD) entries to decide how to move page tables. Meanwhile, process B can concurrently retract page tables under rmap locks. Because the rmap locks are acquired only after the PMD entry is read, a race occurs where move_normal_pmd() can populate bogus PMD entries, potentially mapping physical page 0 as a page table. On x86 architectures, this can lead to a user-to-kernel privilege escalation exploit. The fix involves rechecking the PMD entry after acquiring rmap locks to ensure it still points to a page table, falling back to safer PTE-level copying if not. Exploiting this vulnerability requires the ability to create shared memory (shmem) or file-backed THP mappings on tmpfs with specific mount flags, which typically requires creating user and mount namespaces. This limits exploitability to environments where such capabilities are granted or misconfigured. The vulnerability is rated with a CVSS 3.1 score of 7.0 (High), reflecting its complexity and potential impact on confidentiality, integrity, and availability. No known exploits are currently reported in the wild.

For European organizations, the impact of CVE-2024-50066 can be significant, especially for those running Linux servers or workstations with kernels vulnerable to this flaw. Successful exploitation allows local attackers with limited privileges to escalate to kernel-level privileges, potentially gaining full control over the affected system. This can lead to unauthorized access to sensitive data, disruption of services, and the ability to install persistent malware or backdoors. Organizations relying on Linux-based infrastructure for critical services, cloud environments, or container orchestration platforms may face increased risk if attackers can leverage this vulnerability to compromise host systems. The requirement for specific tmpfs mount configurations and namespace capabilities somewhat limits the attack surface, but environments that allow unprivileged user namespaces or have misconfigured tmpfs mounts could be at higher risk. Additionally, the vulnerability could be leveraged in multi-tenant environments or shared hosting scenarios common in European data centers, increasing the potential for cross-tenant attacks.

1. Patch promptly: Apply the latest Linux kernel updates that include the fix for CVE-2024-50066 as soon as they become available from your distribution vendor. 2. Restrict user namespaces: Disable or restrict unprivileged user namespaces where possible, as creating the necessary tmpfs mounts with required flags often requires user+mount namespaces. 3. Harden tmpfs usage: Review and restrict the use of tmpfs mounts with huge=advise or other THP-related mount options, especially for untrusted users or containers. 4. Limit capabilities: Use Linux Security Modules (e.g., SELinux, AppArmor) or container runtime security profiles to restrict capabilities that allow mounting filesystems or manipulating memory mappings. 5. Monitor for suspicious activity: Implement monitoring for unusual madvise() calls or memory remapping operations that could indicate exploitation attempts. 6. Use kernel lockdown features: Where applicable, enable kernel lockdown modes to reduce the attack surface for privilege escalation. 7. Audit and restrict container configurations: Ensure container runtimes do not grant unnecessary privileges or capabilities that could enable exploitation of this vulnerability. 8. Educate system administrators about the risks of enabling experimental kernel features like CONFIG_READ_ONLY_THP_FOR_FS and the implications for security.