Description
In the Linux kernel, the following vulnerability has been resolved:

x86/shstk: Prevent deadlock during shstk sigreturn

During sigreturn the shadow stack signal frame is popped. The kernel does
this by reading the shadow stack using normal read accesses. When it can't
assume the memory is shadow stack, it takes extra steps to makes sure it is
reading actual shadow stack memory and not other normal readable memory. It
does this by holding the mmap read lock while doing the access and checking
the flags of the VMA.

Unfortunately that is not safe. If the read of the shadow stack sigframe
hits a page fault, the fault handler will try to recursively grab another
mmap read lock. This normally works ok, but if a writer on another CPU is
also waiting, the second read lock could fail and cause a deadlock.

Fix this by not holding mmap lock during the read access to userspace.

Instead use mmap_lock_speculate_...() to watch for changes between dropping
mmap lock and the userspace access. Retry if anything grabbed an mmap write
lock in between and could have changed the VMA.

These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only
available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK
depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP
kernels. So drop support for the other configs under the assumption that
the !SMP shadow stack user base does not exist.

Currently there is a check that skips the lookup work when the SSP can be
assumed to be on a shadow stack. While reorganizing the function, remove
the optimization to make the tricky code flows more common, such that
issues like this cannot escape detection for so long.
Published: 2026-05-27
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel’s handling of the shadow stack during a sigreturn contains a lock ordering bug that can lead to a deadlock. When the kernel attempts to read a shadow stack frame and the access faults, the fault handler may recursively acquire the mmap read lock, while another CPU may be holding an mmap write lock. This mismatch follows the concurrency race pattern identified as CWE‑667 and can cause a deadlock that stalls the kernel’s ability to handle signals, effectively disrupting normal operation. The concurrency error results in denial of service and potentially affects overall system availability.

Affected Systems

All Linux kernels compiled for x86 with the shadow stack (X86_USER_SHADOW_STACK) enabled and running on SMP machines are affected. The issue is tied to the PER_VMA_LOCK configuration, which is the default for SMP kernels. Specific kernel versions are not listed, but any build that includes the code paths described in the advisory is potentially vulnerable.

Risk and Exploitability

The CVSS score is 5.5, indicating a moderate severity, and the EPSS score is 0.00094 (<1%), indicating a very low exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that the flaw manifests during normal signal handling, so exploitation likely requires triggering a sigreturn in a context where a page fault occurs, which typically demands local or privileged code execution. Based on the description, it is inferred that even when triggered, the impact is local denial of service through a kernel deadlock rather than remote code execution. The bug presents as a classic concurrency race (CWE‑667) and does not provide a direct code execution path.

Generated by OpenCVE AI on June 17, 2026 at 01:19 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that contains the patch for the shadow stack deadlock bug
  • Ensure the kernel is built with the PER_VMA_LOCK option enabled; verify that X86_USER_SHADOW_STACK is compiled for SMP configurations
  • If a timely kernel update is unavailable, consider disabling the X86_USER_SHADOW_STACK feature in the kernel configuration, noting that it may affect security hardening features

Generated by OpenCVE AI on June 17, 2026 at 01:19 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 16 Jun 2026 01:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-667

Thu, 28 May 2026 03:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-400

Thu, 28 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-821
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


Wed, 27 May 2026 20:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-400

Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: x86/shstk: Prevent deadlock during shstk sigreturn During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA. Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock. Fix this by not holding mmap lock during the read access to userspace. Instead use mmap_lock_speculate_...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA. These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist. Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long.
Title x86/shstk: Prevent deadlock during shstk sigreturn
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-14T17:51:37.005Z

Reserved: 2026-05-13T15:03:33.095Z

Link: CVE-2026-46063

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-05-27T14:17:26.480

Modified: 2026-06-16T01:23:04.410

Link: CVE-2026-46063

cve-icon Redhat

Severity : Low

Publid Date: 2026-05-27T00:00:00Z

Links: CVE-2026-46063 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-06-17T01:30:05Z

Weaknesses