Look up another CVE · open CVE-2026-68172 in the interactive tracker
CVE-2026-68172
arm64: make huge_ptep_get handled unaligned addresses
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem arch/arm64. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-68172 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/arm64/mm/hugetlbpage.c
- What this is
- ARM64 PORT (AARCH64 ARCHITECTURE)MAINTAINERS section matched on arch/arm64/ · linux-arm-kernel@lists.infradead.org · Maintained
Check it on the machine
grep -w CONFIG_HUGETLB_PAGE /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on armhf/armmp, armhf/rt/armmp
- trixieYnot built on armel/rpi, armhf/armmp, armhf/rt/armmp
- forky, sidYnot built on armhf/armmp
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_HUGETLB_PAGE
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-10 (2 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 4.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/arm64
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.16 | 6.18.42 | 9cd4b1a52eff |
| 6.16 | 7.1.6 | f3530aec2656 |
| 6.16 | 7.2 | f73a8edc2ccc |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is in arm64 huge_ptep_get(), reached only from local kernel entry points such as the mincore(2) syscall, hugetlb page-fault handling, and reading /proc/self/pagemap or smaps; there is no network, adjacent-radio, or physical-device path to this code.
- AC:LAttack complexity, low
- On affected arm64 16K kernels with HugeTLB, an unprivileged process can mmap a contiguous-PMD (1G) hugetlb mapping and reliably trigger the bug via mincore() or a write fault at a page-aligned but contpmd-unaligned virtual address; no race or victim state outside attacker control is required.
- PR:LPrivileges required, low
- Exploitation requires only a local unprivileged user who can invoke syscalls and access its own address space (/proc/self/pagemap and mincore on self mappings); no real root, CAP_SYS_ADMIN, or cross-user ptrace privileges are needed.
- UI:NUser interaction, none
- Triggering the flaw needs no action from another user or administrator beyond the attacker running its own syscalls against hugetlb mappings it created; no mount, file-open, or click-through by a victim is required.
- S:UScope, unchanged
- Impact is a kernel oops/panic and possible kernel page-table reads within the same kernel security authority; it does not cross VM, container, or IOMMU boundaries to compromise a separate security domain.
- C:HConfidentiality impact, high
- Misclassifying a contpmd mapping causes huge_ptep_get() to iterate CONT_PTES times over advancing ptep pointers, reading PTE values beyond the valid table and potentially disclosing adjacent kernel page-table/physical-address data before dereferencing an unmapped linear-map address.
- I:NIntegrity impact, none
- The defective path only performs out-of-bounds PTE reads via __ptep_get(); it does not corrupt or write memory, modify page tables, or achieve code execution—only incorrect aggregation of accessed/dirty bits and eventual fatal dereference.
- A:HAvailability impact, high
- Iteration can advance ptep into unmapped linear-map holes or past valid kernel mappings, causing an unhandled kernel page fault and system panic/oops, yielding complete loss of kernel availability on affected arm64 16K HugeTLB systems.