Linux kernel x86 shadow stacks: shstk_pop_sigframe ignores mmap_read_lock_killable() failure on signal return

Impact

On signal return with CET shadow stacks enabled, shstk_pop_sigframe() called mmap_read_lock_killable() but never checked the result, so it proceeded to touch the memory map on a path where the lock was not actually taken - the functions were also missing __must_check, which is why the omission went unnoticed. The record scores the consequence as availability loss on a local, low-privilege vector. This only applies to hosts running kernels with x86 shadow-stack support on CET-capable CPUs and to processes that have shadow stacks turned on, so on most GPU fleets today the reachable surface is small; where it is enabled, an unprivileged local process can reach it through ordinary signal delivery and a killable signal. The practical cost on a GPU node is the usual asymmetry: a cheap local trigger against a host whose other tenants and in-flight jobs are the collateral.

Who can reach it

Local, authenticated: an unprivileged process running with x86 shadow stacks enabled, taking a signal and being interrupted by a killable signal during the sigframe restore. No device or management-network access involved.

What to do

Update to a stable kernel carrying the shstk error-handling and __must_check fix, then drain and reboot each node; this is compiled-in x86 core code with no module or sysctl mitigation. If you are not deliberately running CET shadow stacks on these hosts, the exposure is effectively absent and the fix can ride along with the next routine kernel roll rather than driving its own window.

References

Related entries

• Linux kernel EFI/CPER: oversized offset in a firmware error record makes the kernel dump arbitrary memoryCVE-2026-43171 · Linux kernel EFI/CPER firmware error reporting (cper_print_fw_err length underflow)Medium
• Linux kernel arm64: TSV110 CPUs were not getting the Spectre-BHB software mitigationCVE-2026-43261 · Linux kernel arm64 Spectre-BHB mitigation (TSV110 MIDR missing from the affected list)Medium
• Linux kernel KVM: spurious userspace exit when checking nested events can kill the guestCVE-2026-43265 · Linux kernel KVM x86 nested virtualization (vcpu_block() nested-event check returning -EBUSY)Medium
• Linux kernel EFI/CPER: an oversized ARM processor error record is trusted and read past the firmware bufferCVE-2026-43266 · Linux kernel EFI/CPER ARM processor error record parser (section_length / ERR_INFO_NUM not bounded)Medium
• Linux kernel CephFS client: punch-hole writes without snapshot context silently corrupt existing snapshotsCVE-2026-43273 · Linux kernel CephFS client (ceph_zero_partial_object missing snapshot context on OSD writes)Medium
• Linux kernel KVM nSVM: userspace can trigger a kernel WARN by changing CPUID after loading CR3CVE-2026-43315 · Linux kernel KVM nSVM (user-triggerable WARN in svm_set_nested_state)Medium