CVE-2026-31398 in Linux
摘要
由 VulDB • 2026-06-15
This is a Linux kernel crash dump (specifically an **Oops** or **Panic**) occurring on an **ARM64** architecture.
### **Summary of the Issue** The kernel crashed while trying to **unmap a page** during memory reclaim (shrinking the LRU list). The crash happened inside `page_table_check_set`, which is a debug feature that validates page table entries.
The most likely cause is a **bug in the kernel's memory management code** related to **Contiguous Page Table Entries (ContPTEs)** or a race condition during page unmapping, triggered by a user-space write to `/sys/kernel/mm/.../reclaim` (proactive memory reclaim).
---
### **Detailed Analysis**
#### **1. Crash Location** ``` [ 21.142093] page_table_check_set+0x28c/0x2a8 (P)
``` - **`page_table_check_set`**: This is a **debugging function** enabled by `CONFIG_PAGE_TABLE_CHECK`. It verifies that page table entries are being set correctly (e.g., no invalid permissions, no corruption). - The `(P)` indicates the crash happened in **privileged mode** (kernel mode). - The crash suggests that the kernel tried to set a page table entry that violated the checks (e.g., invalid flags, inconsistent state).
#### **2. Call Trace Analysis** The call trace shows the sequence of events leading to the crash:
1. **`user_proactive_reclaim` / `reclaim_store`**: - A user-space process wrote to a sysfs attribute (likely `/sys/kernel/mm/.../reclaim` or similar) to trigger proactive memory reclaim. - This is a **normal operation** but can stress the memory subsystem.
2. **`shrink_folio_list` / `shrink_lruvec` / `shrink_node`**: - The kernel is trying to free memory by shrinking the Least Recently Used (LRU) lists. - It iterates over pages and tries to unmap them.
3. **`try_to_unmap` / `rmap_walk_anon`**: - The kernel is walking reverse mappings (rmap) for an **anonymous page** (not backed by a file). - It calls `try_to_unmap_one` to remove the page from the page tables.
4. **`contpte_set_ptes` / `__set_ptes_anysz.constprop.0`**: - **Key Clue**: The kernel is using **Contiguous Page Table Entries (ContPTEs)**. - ContPTEs allow multiple physical pages to be mapped with a single large page table entry (e.g., 2MB or 1GB instead of 4KB). - The crash occurs when trying to **set** the page table entries during unmapping. This suggests a bug in how ContPTEs are handled during unmap or a race condition.
5. **`__page_table_check_ptes_set` / `page_table_check_set`**: - The debug check fails because the page table entry being set is invalid or inconsistent.
#### **3. Register Values (ARM64)** - **`x0`**: `ffff0000c08228c0` – Likely a pointer to the page table entry or folio. - **`x1`**: `0000000000000000` – Possibly a flag or offset. - **`x2`**: `0000000000134510` – Possibly a PTE value or address. - **`x3`**: `0000000000000002` – Possibly a count or flag. - **`x4`**: `0000000000000001` - **`x5`**: `ffff00017fffce00` – Likely a pointer to memory or struct. - **`x6`**: `000000004000ffff` - **`x7`**: `005c03e000040000` - **`x8`**: `0000000000000001` - **`x9`**: `ffffd1a55c079ee0` - **`x10`**: `005c000000000000`
These registers don't immediately reveal the exact bug without the source
If you want to get best quality of vulnerability data, you may have to visit VulDB.