CVE-2026-46063: Linux Kernel Race Condition Vulnerability

CVE-2026-46063 Overview

CVE-2026-46063 is a deadlock vulnerability in the Linux kernel's x86 shadow stack (shstk) implementation. The flaw lives in the signal return path, where the kernel pops the shadow stack signal frame from userspace. To validate that the memory being read is actual shadow stack memory, the kernel holds the mmap read lock and inspects the VMA flags during the access.

This pattern is unsafe. If the read triggers a page fault, the fault handler attempts to recursively acquire another mmap read lock. When a writer on another CPU is queued, the recursive read lock acquisition can fail and produce a deadlock on the affected task.

Critical Impact
A local user process exercising shadow stack signal handling on x86 can trigger a kernel deadlock, stalling the task and contending threads under specific scheduling and page fault conditions.

Affected Products

Linux kernel x86 builds with X86_USER_SHADOW_STACK enabled
SMP x86 kernels configuring PER_VMA_LOCK for shadow stack support
Linux distributions shipping affected stable kernels prior to the referenced fix commits

Discovery Timeline

2026-05-27 - CVE-2026-46063 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-46063

Vulnerability Analysis

The defect resides in the x86 shadow stack sigreturn logic. During sigreturn, the kernel reads the shadow stack signal frame from userspace using normal read accesses. Because that memory could otherwise be ordinary readable memory, the kernel takes additional steps to confirm the target VMA is shadow stack before trusting the data.

The original implementation performed the userspace read while holding the mmap read lock and checking VMA flags inline. This is incorrect on x86 Linux. A page fault during the userspace access calls back into the fault handler, which itself needs the mmap read lock. Recursive read lock acquisition is normally permitted, but Linux read-write semaphores are queue-fair: if a writer is already waiting, a second reader on the same task blocks behind the writer, while the writer waits on the first reader, completing a deadlock cycle.

The fix removes the lock-held userspace access. Instead, it uses the mmap_lock_speculate_...() helpers to detect VMA mutations between dropping the lock and performing the read, retrying when a writer has intervened. These helpers depend on mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured, so X86_USER_SHADOW_STACK now depends on PER_VMA_LOCK. The patch also removes a prior fast-path optimization that skipped the VMA lookup when the SSP was assumed to be on a shadow stack, ensuring the tricky code path is exercised consistently.

Root Cause

The root cause is unsafe locking [CWE-667] in the shadow stack sigreturn handler. Holding the mmap read lock across a userspace memory access permits recursive read-lock acquisition through the page fault path, which deadlocks against a queued writer on another CPU.

Attack Vector

Exploitation requires a local context on an x86 system with user shadow stack support compiled in and active. A process using shadow stacks can craft signal delivery and sigreturn sequences that cause the shadow stack frame read to take a page fault while another CPU contends for the mmap write lock. The result is a deadlocked task and potential cascading contention on the affected mm.

No code example is published with this advisory. See the upstream commits referenced below for the exact source-level changes.

Detection Methods for CVE-2026-46063

Indicators of Compromise

Hung tasks on x86 hosts reporting blocked threads in shadow stack sigreturn paths, visible in dmesg hung task warnings.
Soft lockup or rwsem contention traces involving mmap_lock together with shadow stack symbols.
Processes built with -fcf-protection and shadow stack enabled becoming unresponsive after signal delivery under memory pressure.

Detection Strategies

Compare running kernel build identifiers against fixed stable commits 3d29db8, 4f3374c, 9874b29, d042d69, and e2c2b04 referenced in the advisory.
Audit kernel configurations for CONFIG_X86_USER_SHADOW_STACK=y without the corresponding PER_VMA_LOCK dependency fix applied.
Correlate hung task watchdog output with workloads that use user shadow stacks to identify suspect deadlocks.

Monitoring Recommendations

Enable hung_task_panic or hung task warnings (kernel.hung_task_timeout_secs) on production x86 hosts and forward warnings to a central log pipeline.
Collect /proc/lockdep and rwsem contention metrics where available to spot unusual mmap_lock queueing.
Track kernel package versions through configuration management to ensure deployed kernels include the upstream fixes.

How to Mitigate CVE-2026-46063

Immediate Actions Required

Apply the stable kernel updates that include the upstream fix commits to all affected x86 hosts running shadow-stack-enabled kernels.
Identify workloads built with Intel CET shadow stack support and prioritize their hosts for patching.
Restrict local access on multi-tenant x86 systems until patched, since exploitation requires a local process.

Patch Information

The issue is resolved by removing the mmap read lock from the userspace shadow stack access path and using speculative mmap lock helpers, while making X86_USER_SHADOW_STACK depend on PER_VMA_LOCK. Fixes are available in the following upstream commits: Kernel Git Commit 3d29db8, Kernel Git Commit 4f3374c, Kernel Git Commit 9874b29, Kernel Git Commit d042d69, and Kernel Git Commit e2c2b04.

Workarounds

Rebuild affected kernels with CONFIG_X86_USER_SHADOW_STACK disabled where shadow stack protection is not required, removing the vulnerable code path entirely.
For workloads that do not depend on Intel CET shadow stack, launch processes without shadow stack via arch_prctl(ARCH_SHSTK_DISABLE, ...) or by building binaries without -fcf-protection=return.
Limit untrusted local users on x86 systems running affected kernels until patches are deployed.

bash

# Verify kernel version and shadow stack configuration on x86 hosts
uname -r
grep -E 'CONFIG_X86_USER_SHADOW_STACK|CONFIG_PER_VMA_LOCK' /boot/config-$(uname -r)

# Check for hung task warnings related to mmap_lock or shstk
dmesg | grep -Ei 'hung_task|mmap_lock|shstk|shadow stack'