Look up another CVE · open CVE-2026-72043 in the interactive tracker
CVE-2026-72043
LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem arch/loongarch. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72043 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 | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When hardware page table walker (PTW) is enabled on LoongArch, the CPU may set _PAGE_DIRTY directly in the page table entry during a write TLB miss, without going through the software TLB store handler. The software TLB store handler (tlbex.S:254) sets both _PAGE_DIRTY and_PAGE_MODIFIED together: ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED) Since hardware PTW only sets _PAGE_DIRTY, the software-only bit, i.e. _PAGE_MODIFIED is left unchanged. This creates a window where a PTE has _PAGE_DIRTY set (hardware knows the page is dirty) but _PAGE_MODIFIED clear (software is unaware). When fork()/clone() triggers copy-on-write, __copy_present_ptes() calls pte_wrprotect(), which unconditionally clears both the _PAGE_WRITE and _PAGE_DIRTY bits: pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY); Since _PAGE_MODIFIED was never set, the dirtiness information is lost completely. Subsequently, when memory pressure triggers page reclaim, page_mkclean() / try_to_unmap() sees the page as clean (i.e. pte_dirty() returns false) and the page may be freed without writeback, causing data corruption. Fix this by propagating the _PAGE_DIRTY bit to the _PAGE_MODIFIED bit in both pte_wrprotect() and pmd_wrprotect() before clearing writeable bits: if (pte_val(pte) & _PAGE_DIRTY) pte_val(pte) |= _PAGE_MODIFIED; The pmd_wrprotect() fix handles the CONFIG_TRANSPARENT_HUGEPAGE case, where pmd entries need the same treatment. This ensures the software dirty tracking bit (checked by pte_dirty() and pmd_dirty(), which read both the _PAGE_DIRTY and _PAGE_MODIFIED bits) is preserved across fork COW write-protection. The issue was found by the LTP madvise09 test case, which exercises page reclaim after "madvise(MADV_FREE), write and fork" operation sequence on private anonymous mappings.
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/loongarch/include/asm/pgtable.h
- What this is
- LOONGARCHMAINTAINERS section matched on arch/loongarch/ · loongarch@lists.linux.dev · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
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
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Nsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/loongarch
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.19 | 6.1.178 | 76f88650763a |
| 5.19 | 6.6.145 | e8a916579e42 |
| 5.19 | 6.12.97 | 39bb21a4bff0 |
| 5.19 | 6.18.40 | a65f49b6f7ec |
| 5.19 | 7.1.5 | e483da960892 |
| 5.19 | 7.2 | 018e9828eb52 |
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 triggered via local syscalls (mmap/madvise/write/fork or clone) through dup_mmap()->copy_page_range()->pte_wrprotect() on LoongArch; it is not reachable from network-facing kernel services.
- AC:LAttack complexity, low
- An unprivileged attacker can reliably reproduce the LTP madvise09 sequence (MADV_FREE, write, fork, then force reclaim) on LoongArch CPUs with hardware PTW; no races or victim-specific state beyond attacker-controlled memory pressure are required.
- PR:LPrivileges required, low
- No special capabilities are needed; any local user can create private anonymous or file-backed COW mappings, write them, fork, and drive page reclaim using standard unprivileged syscalls.
- UI:NUser interaction, none
- Exploitation requires no action from another user; the attacker controls the full trigger sequence in their own process or in a service worker they operate.
- S:UScope, unchanged
- Impact is confined to kernel memory-management integrity on the host; it does not constitute a VM escape, sandbox escape, or IOMMU/DMA boundary bypass.
- C:HConfidentiality impact, high
- Incorrectly treating hardware-dirty pages as clean during reclaim can free page frames without writeback or swap, leaving prior contents in the buddy allocator for reuse by other mappings and enabling cross-process information disclosure.
- I:HIntegrity impact, high
- Lost dirty tracking causes silent discard of modified pages during reclaim without writeback, corrupting private anonymous data and file-backed COW mappings when dirty pages are freed or swapped incorrectly.
- A:NAvailability impact, none
- The defect causes silent data corruption rather than kernel oops, panic, or hang; the system remains operational even when pages are incorrectly reclaimed.