Security Bug Identified in Linux 6.6: CVE-2024-50066
/ 3 min read
Quick take - A security-related race condition, designated as CVE-2024-50066, has been identified in Linux 6.6 involving the mremap() function and Transparent Huge Page (THP) code, which could allow attackers to exploit vulnerabilities by manipulating page tables under specific conditions, with proposed solutions and a patch already in development.
Fast Facts
- A security race condition (CVE-2024-50066) has been found in Linux 6.6, affecting the
mremap()function and Transparent Huge Page (THP) code. - Exploitation requires creating unprivileged namespaces, potentially allowing attackers to install physical address 0 as a page table, leading to security vulnerabilities.
- The issue arises when multiple processes manipulate the same tmpfs file with THP enabled, causing unintended sharing of page tables and stale TLB entries.
- Proposed mitigations include broadening rmap locks and adding recheck/retry logic; a patch is available in the MM tree and marked fixed in stable releases 6.6.58 and 6.11.5.
- The bug disclosure is subject to a 90-day deadline, set for December 31, 2024, with public reporting 30 days after any fix release.
Security-Related Race Condition Identified in Linux 6.6
A security-related race condition has been identified in Linux 6.6. The issue is specifically between the mremap() function and the Transparent Huge Page (THP) code. This bug has been designated as CVE-2024-50066.
Exploitation Risks
Exploitation of this bug requires the ability to create unprivileged namespaces. If successfully exploited, attackers could install physical address 0 as a page table, posing various security risks. The race condition can occur when multiple processes trigger the bug simultaneously, leading to unintended sharing of page tables. Such a situation may result in stale Translation Lookaside Buffer (TLB) entries, which could point to freed pages, creating potential vulnerabilities.
The race condition is particularly relevant when two processes manipulate the same tmpfs file with THP enabled, exacerbating the problem. The bug is specifically linked to the move_page_tables() function, which manages page table entries during the mremap() process. During this process, the mmap_lock is held in write mode, but no reverse mapping (rmap) locks are initially held, leading to potential inconsistencies when move_normal_pmd() is called.
Proposed Solutions
To mitigate the issue, two primary solutions have been proposed: broadening the scope of rmap locks and implementing additional recheck/retry logic. A test case has been developed to reproduce the issue, triggering a kernel error when attempting to unmap the page table at physical address 0. The exploitability of this bug may hinge on whether a struct page has been allocated for physical address 0. The bug requires the creation of shared memory (shmem) or file THP mappings, while anonymous THP utilizes different code paths.
In addition to the main security bug, two theoretical races were identified, though they are not considered immediate security concerns. The second non-issue involves a potential race in move_ptes() and MADVISE_COLLAPSE, believed to have negligible impact. The third non-issue addresses a potential race in move_huge_pmd and split_huge_page_to_list_to_order, which may lead to an anonymous page disappearing from a Virtual Memory Area (VMA) but is without significant consequences.
Current Status and Disclosure
A patch for the security bug is currently in the MM (Memory Management) tree and has been marked as fixed in the stable releases 6.6.58 and 6.11.5. The disclosure of this bug is subject to a 90-day deadline, set for December 31, 2024. If a fix becomes available before this deadline, the bug report will be made public 30 days after the fix is released.
Original Source: Read the Full Article Here
