From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-74672][MODERATE 7.0] mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Date: Sat, 22 Aug 2026 15:39:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-74672 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 7 X-AL-KERNEL-ActionableScore-Lower: 3 X-AL-KERNEL-Commit: c5bf8cd148cfea948cfa3db71da427294b20db0f List-Id: CVE: CVE-2026-74672 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: YES Patch: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Commit: c5bf8cd148cfea948cfa3db71da427294b20db0f Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5bf8cd148cfea948cfa3db71da427294b20db0f Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74672 Analysis date: Sat, 22 Aug 2026 15:39:51 -0400 ActionableScore: 7 ActionableScore lower bound: 3 Actionable bucket: Strong Important candidate / Actionable Moderate at minimum Manual review required: YES Summary: A race between ptdump page-table walking and huge vmap page-table promotion can let ptdump access a freed lower-level page table, causing a kernel use-after-free and possible memory corruption, with practical reachability usually limited to local privileged or delegated debug access. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-74672 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74672 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: MODERATE 7.0 Manual review required: YES A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-74672 MODERATE CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-362;CWE-667;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'ptdump can walk kernel page tables it does not own while vmap huge mapping promotion can replace a lower level page table with a huge P4D PUD or PMD entry and free the old table. A race between these paths can let ptdump access a freed page table, resulting in use-after-free, memory corruption, or a kernel crash. For the CVSS the PR:L is used for the paranoid score because reliable triggering may be possible from a local user or less privileged service context if ptdump or related debug page table walking is exposed or invoked in the environment. The issue is not directly network reachable and requires local activity plus a timing window, so AC:H is appropriate. Impact is at least local denial of service and the UAF primitive makes limited or full confidentiality and integrity impact plausible enough for manual review.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Strong Important candidate / Actionable Moderate at minimum (with actual score 5) YES WRITE OOB LOCK DEADLOCK DANGER INIT RACE UAF HARDWARE SYZBOT KPANIC MEMORY NO NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=7 ActionableScoreLower=3 ## 1. ActionableScore * Conservative score: 3 * Paranoid score: 7 * Final recommended bucket: **Strong Important candidate / Actionable Moderate at minimum**:: ## 2. Signal breakdown ### Conservative score signals * Generic memory corruption, UAF: +2 The commit explicitly states that ptdump can access a freed page table after vmap promotes a lower page table into a huge P4D/PUD/PMD entry. * Real lifetime corruption: +1 The bug is a page table lifetime race where vmap frees a lower page table while ptdump may still be walking it. * Reliable kernel crash / strong DoS: +1 A stale page table walk can lead to UAF, invalid access, and kernel crash. * Privileged high-value MMU/page-table path: +1 The affected objects are kernel page tables and huge vmalloc mappings, which are high-value kernel memory-management structures. * Hard or unreliable race / timing window: -1 Triggering requires overlap between ptdump walking and vmap huge page table promotion/freeing. * Requires admin/root/debug access in typical deployments: -2 ptdump/debug page table walking is normally exposed only through privileged debugging interfaces. Conservative total: 3 ### Paranoid score signals * Generic memory corruption, UAF: +2 * Real lifetime corruption: +1 * Reliable kernel crash / strong DoS: +1 * Privileged high-value MMU/page-table path: +1 * Confidentiality impact plausible: +1 In the paranoid interpretation, a stale page table walk over reused memory may expose or process unintended kernel memory state through the debug walker. * Integrity impact plausible: +1 The affected state is kernel page-table metadata, and the commit explicitly describes memory corruption, even though no arbitrary write primitive is shown. * Broad/core memory-management path: +1 vmalloc huge mappings and kernel page-table manipulation are core kernel MM paths, even if ptdump itself is privileged/debug oriented. * Hard or unreliable race / timing window: -1 Paranoid total: 7 No privilege-escalation bonus is awarded because the patch does not show attacker-controlled reclaim, object replacement, callback control, arbitrary write, or a demonstrated LPE primitive. ## 3. Reachability analysis The practical trigger requires ptdump to walk kernel page tables while vmap concurrently promotes mappings to huge entries and frees the lower page table. In normal deployments, ptdump is usually a privileged debug path, so the conservative interpretation treats this as requiring root or equivalent debug access. Namespaces and containers generally do not make this reachable to an ordinary unprivileged user unless the host exposes debugfs or ptdump-like functionality into a delegated environment. A reduced-capability root, container root, or service account with access to such debug interfaces should not be treated as full host-root for practical triage, which is why the paranoid score does not fully dismiss the issue. The path is not network reachable. Realistic exploitation conditions require local activity, privileged or delegated debug access, huge vmap promotion, and a race window. Call-site confidence: high. The commit message directly describes the relevant ptdump and vmap interaction, and the patch changes vmap_try_huge_pmd(), vmap_try_huge_pud(), vmap_try_huge_p4d(), and walk_page_range_debug() locking assertions. ## 4. Severity interpretation This is not an ordinary Moderate cleanup because the patch fixes an explicit kernel UAF involving page table lifetime. The realistic demonstrated impact is closer to local privileged DoS, since the known trigger path is ptdump and no practical unprivileged exploit primitive is shown. However, the affected objects are kernel page tables and the commit explicitly mentions UAF and memory corruption. For triage, this should be treated as at least Actionable Moderate and a Strong Important candidate under the paranoid interpretation. The main uncertainty is exploitability beyond crash, not whether a real lifetime bug exists. ## 5. One-sentence report phrase A race between ptdump page-table walking and huge vmap page-table promotion can let ptdump access a freed lower-level page table, causing a kernel use-after-free and possible memory corruption, with practical reachability usually limited to local privileged or delegated debug access. ## 6. Manual review recommendation MANUAL CHECK REQUIRED Reason: explicit UAF plus memory corruption in kernel page-table handling is high-risk enough for manual review, even though the conservative practical trigger appears privileged and race-dependent. ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Commit: c5bf8cd148cfea948cfa3db71da427294b20db0f Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5bf8cd148cfea948cfa3db71da427294b20db0f Commit description: Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable freeing", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45 ("arm64: Enable vmalloc-huge with ptdump"), which this series has to deal with carefully. This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45 ("arm64: Enable vmalloc-huge with ptdump"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch. There are related issues that are also addressed in this series: * x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked. The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) [Commit description truncated; see the upstream URL below] Changed files: mm/20260706203128.162335-1-devnexen include/linux/mmap_lock.h mm/pagewalk.c mm/vmalloc.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5bf8cd148cfea948cfa3db71da427294b20db0f ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-74672 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74672 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H The Best / paranoid CVSS score: 7 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 3 Paranoid ActionableScore: 7 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: MODERATE KPANIC detected for this report: YES Published priority for this report (same as in Subject): MODERATE 7.0 These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).