CVE-2026-46063

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