CVE-2026-46063: x86/shstk: Prevent deadlock during shstk sigreturn
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.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel reliability flaw in x86 user shadow stack signal return handling. A process hitting a specific page fault while another CPU waits on memory-map locks can deadlock the affected path. Business impact is availability risk on affected Linux systems using this feature; sources do not show data theft or active exploitation.
Executive priority
Track as a moderate availability risk. It does not currently warrant emergency action absent active exploitation, but kernel fixes require planned maintenance and reboot coordination. Prioritize shared compute, developer workstations, and systems running untrusted local workloads.
Technical view
During shstk sigreturn, the kernel reads a shadow stack signal frame while holding mmap read lock to confirm VMA flags. If that userspace read faults, fault handling can attempt a recursive mmap read lock; with a pending writer, the lock can deadlock. The fix drops the lock around userspace access and uses mmap_lock_speculate helpers.
Likely exposure
Exposure is most likely on x86 Linux systems with user shadow stack support enabled and kernels in the affected ranges. The source lists Linux versions including 6.6, 6.6.140, 6.12.88, 6.18.27, 7.0.4, and 7.1 as affected, but package-level distro status is not provided.
Exploitation context
CISA KEV status is false, and the provided sources do not report public exploitation. The described condition requires shadow stack sigreturn, a userspace read fault, and mmap lock contention. Treat it as a denial-of-service style kernel availability issue unless vendor advisories add stronger impact evidence.
Researcher notes
The CVE metadata lacks CVSS, CWE, and distro package mapping. Affected-version data includes duplicate commit-hash entries and a broad version list, so validate using kernel stable commits and downstream vendor advisories. Avoid assuming exploitability beyond the documented deadlock condition.
Mitigation direction
Update affected Linux kernels to vendor releases containing the referenced stable fixes.
Check Linux distribution advisories for package names, fixed builds, and reboot requirements.
Prioritize internet-facing or multi-tenant Linux hosts where local code execution is plausible.
If no fixed package exists, ask the vendor for supported mitigation guidance.
Validation and detection
Inventory x86 Linux kernel versions across servers, containers hosts, and appliances.
Confirm whether user shadow stack support is enabled in kernel configuration.
Map installed kernel builds against distribution advisories and referenced stable commits.
After patching, verify systems boot the fixed kernel, not an older retained kernel.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-46063 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 27, 2026, 12:57 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.