CVE-2025-38195

What it actually does

NULL pointer dereference in huge_pte_offset() on LoongArch when a PMD entry is absent during hugetlb page table walks triggered by madvise and get_user_pages operations, resulting in a kernel paging fault at address 0x0 and immediate panic.

Why it matters to the business

Unprivileged local processes can trigger kernel crashes that reboot or halt affected Linux systems, causing unplanned downtime, loss of running workloads, and potential data corruption in memory-intensive applications; the issue affects widely deployed kernel versions until 6.6.95.

How an attack unfolds

An attacker with local access maps a huge-page-backed region, issues an madvise call that forces page-fault handling through hugetlb_follow_page_mask, and reaches the unchecked NULL PMD path in huge_pte_offset, producing a deterministic kernel panic; no remote vector or privilege escalation is required.

How to fix it

Upgrade the Linux kernel to version 6.6.95 or later; for Chainguard images update tigera-operator-fips-1.29 to 1.29.8-r22; apply the commit b427d98d55217b53c88643579fbbd8a4c351a105 from stable trees; reboot after installation and verify the new kernel is running.

How to confirm the fix worked

Confirm the running kernel reports version 6.6.95 or newer; attempt to reproduce the original madvise/hugetlb sequence in a test environment and verify absence of the NULL dereference panic; inspect dmesg for the fixed call trace pattern.

Typical attack path

1. Obtain local unprivileged shell on target system
2. Create or attach to a memory region backed by huge pages
3. Invoke madvise with behavior flags that walk page tables via faultin_page_range
4. Trigger NULL PMD dereference inside huge_pte_offset leading to panic

How to detect it

Search kernel logs and crash dumps for the exact call trace starting with huge_pte_offset+0x3c/0x58 followed by hugetlb_follow_page_mask, __get_user_pages, faultin_page_range, and madvise_vma_behavior; correlate with sys_madvise system-call entries in audit or strace output around the time of the panic.

• huge_pte_offset+0x3c/0x58
• hugetlb_follow_page_mask+0x74/0x438
• CPU .* Unable to handle kernel paging request at virtual address 0x0

What your security team should do

• Prioritize kernel updates to 6.6.95 on all LoongArch systems within the next maintenance window
• Add kernel version checks to configuration management and image build pipelines
• Monitor for oops/panic reports containing huge_pte_offset and hugetlb_follow_page_mask until patches are deployed