AZL-42186
See a problem?- Import Source
- https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-42186.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/AZL-42186
- Upstream
- Published
- 2024-05-01T06:15:21Z
- Modified
- 2026-04-01T05:14:30.569151Z
- Severity
-
- 7.8 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CVSS Calculator
- Summary
- CVE-2024-27022 affecting package kernel for versions less than 6.6.35.1-4
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
fork: defer linking file vma until vma is fully initialized
Thorvald reported a WARNING [1]. And the root cause is below race:
CPU 1 CPU 2 fork hugetlbfsfallocate dupmmap hugetlbfspunchhole immaplockwrite(mapping); vmaintervaltreeinsertafter -- Child vma is visible through immap tree. immapunlockwrite(mapping); hugetlbdupvmaprivate -- Clear vmalock outside immaprwsem! immaplockwrite(mapping); hugetlbvmdeletelist vmaintervaltreeforeach hugetlbvmatrylockwrite -- Vmalock is cleared. tmp->vmops->open -- Alloc new vmalock outside immaprwsem! hugetlbvmaunlockwrite -- Vmalock is assigned!!! immapunlockwrite(mapping);
hugetlbdupvmaprivate() and hugetlbvmopopen() are called outside immaprwsem lock while vma lock can be used in the same time. Fix this by deferring linking file vma until vma is fully initialized. Those vmas should be initialized first before they can be used.
- References