CVE-2026-23345: Linux Kernel Privilege Escalation Flaw

CVE-2026-23345 Overview

A kernel vulnerability has been resolved in the Linux kernel affecting arm64 systems with Guarded Control Stack (GCS) mappings when FEAT_LPA2 (Large Physical Address Extension 2) is enabled. The vulnerability occurs because the _PAGE_GCS and _PAGE_GCS_RO macros incorrectly include PTE_SHARED bits set to 0b11, which when FEAT_LPA2 is enabled, are repurposed as bits 50-51 of the output address instead of the shareability attribute. This misinterpretation leads to kernel paging request failures and system panics.

Critical Impact

When GCS is enabled on systems with FEAT_LPA2, the incorrect PTE configuration causes level 0 translation faults, leading to kernel panics and potential denial of service conditions during memory management operations.

Affected Products

• Linux kernel with arm64 architecture support
• Systems with FEAT_LPA2 enabled (52-bit virtual addresses)
• Configurations using Guarded Control Stack (GCS) mappings

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23345 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23345

Vulnerability Analysis

This vulnerability represents a kernel-level memory corruption issue in the Linux kernel's arm64 architecture support. The core problem lies in the interaction between Page Table Entry (PTE) attributes and the FEAT_LPA2 feature set.

When FEAT_LPA2 is enabled on arm64 systems, the memory architecture undergoes a significant change: bits 8-9 of the PTE, which traditionally represent the shareability attribute (PTE_SHARED), are repurposed to represent bits 50-51 of the output physical address. The _PAGE_GCS and _PAGE_GCS_RO macro definitions include PTE_SHARED bits set to 0b11 to maintain consistency with other _PAGE_* definitions, but this creates an incorrect address mapping when FEAT_LPA2 is active.

The result is catastrophic: when the kernel attempts to access GCS-protected memory regions, it computes an invalid physical address due to the misinterpreted PTE bits. This leads to level 0 translation faults, as evidenced by the panic output showing an attempt to access virtual address fffff1ffc32d8008 with ESR (Exception Syndrome Register) value 0x0000000096000004, indicating a data abort at the current exception level.

Root Cause

The root cause stems from the architectural assumption embedded in the _PAGE_GCS{,_RO} macro definitions. These macros were designed with the shareability bits (PTE_SHARED) included as 0b11, following the pattern established by other page protection macros. However, ARM's FEAT_LPA2 extension fundamentally changes the meaning of these bits in the PTE structure.

The fix introduces a gcs_page_prot variable that dynamically stores the appropriate protection bits, clearing PTE_SHARED when LPA2 is detected as enabled. This approach mirrors the existing handling in the kernel's protection_map[] array. Additionally, the unused PAGE_GCS and PAGE_GCS_RO macros were removed to prevent future misuse.

Attack Vector

The vulnerability is triggered during normal kernel memory management operations involving GCS mappings on affected systems. The call trace from the panic report shows the fault occurring in the zap_huge_pmd() function during memory unmapping operations:

The crash occurs through the following execution path:

• gcs_free() initiates GCS memory cleanup
• vm_munmap() → __vm_munmap() → do_vmi_munmap() process the unmapping request
• unmap_vmas() → unmap_single_vma() → unmap_page_range() traverse the VMA structures
• zap_huge_pmd() attempts to zap a huge PMD entry and encounters the corrupted PTE
• The invalid address computation triggers a level 0 translation fault (FSC = 0x04)

This vulnerability requires local access to trigger, as it manifests during process exit or explicit memory deallocation on systems with GCS enabled.

Detection Methods for CVE-2026-23345

Indicators of Compromise

• Kernel panic messages containing "Unable to handle kernel paging request" with addresses in the fffff1ffc* range
• ESR values of 0x0000000096000004 indicating DABT (Data Abort) at current EL with level 0 translation fault
• Call traces showing zap_huge_pmd, gcs_free, or mm_release function involvement
• System crashes occurring specifically when processes using GCS exit or free GCS memory

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for "level 0 translation fault" errors on arm64 systems
• Deploy monitoring for unexpected kernel panics with call traces involving gcs_* functions
• Audit system configuration for FEAT_LPA2 and GCS enablement on arm64 platforms
• Implement crash dump analysis to identify PTE-related faults in GCS memory regions

Monitoring Recommendations

• Enable kdump or similar crash dump mechanisms to capture diagnostic data during kernel panics
• Configure alerting for kernel oops messages containing arm64-specific GCS or LPA2 references
• Monitor system stability metrics on arm64 servers running kernel versions prior to the patch
• Review application logs for processes that may be using GCS features and experiencing unexpected terminations

How to Mitigate CVE-2026-23345

Immediate Actions Required

• Update to a patched Linux kernel version containing the GCS/LPA2 fix
• On unpatched systems, consider disabling GCS if operational requirements permit
• Review arm64 deployment configurations to identify systems with both FEAT_LPA2 and GCS enabled
• Prioritize patching for systems running workloads that utilize Guarded Control Stack features

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix introduces a gcs_page_prot variable that stores the protection bits and conditionally clears PTE_SHARED when LPA2 is enabled. The following commits contain the fix:

• Kernel Git Commit 1df3ef7
• Kernel Git Commit 8a85b31
• Kernel Git Commit ca1684dd

Apply the appropriate patch for your kernel version and rebuild or update the kernel package.

Workarounds

• Disable Guarded Control Stack features via kernel configuration (CONFIG_ARM64_GCS=n) if not required for security purposes
• Consider disabling FEAT_LPA2 if operationally feasible, though this may impact systems requiring 52-bit virtual address space
• Implement process isolation to limit exposure of GCS-using applications on affected systems
• Deploy kernel live patching solutions if available to apply fixes without system reboots

# Check if your arm64 system has LPA2 enabled
cat /proc/cpuinfo | grep -i lpa2

# Verify GCS configuration in kernel
zcat /proc/config.gz | grep ARM64_GCS

# Monitor for related kernel panics
dmesg -w | grep -E "(translation fault|gcs_|PTE_SHARED)"