HJ reported a crash when running a new glibc test added two weeks ago, 
with his (out of tree) rebased glibc shadow stack patches on top. The 
issue turned out to be a bug in shadow stack clone error handling. The new 
test exercises clone(CLONE_PIDFD|CLONE_VFORK) with the fd limit exhausted, 
which causes the clone to fail after the shadow stack handling. A failure 
at that point will normally try to clean up the shadow stack that it 
allocated before returning the error to userspace. But for vfork, it 
should not do this as nothing was allocated and the thread's shadow stack 
is the parent's shadow stack too. The logic for not unmapping the thread's 
shadow stack for CLONE_VFORK children works in the normal (exec() or 
exit()) case, but is buggy in the clone failure case. So on clone failure 
with those particular args, the parent will end up with a missing shadow 
stack.

When working on the solution I did a review of the surrounding logic and 
found another more minor issue.

Patch 1 is the bug fix for the main issue, and 2 is the other issue. Patch
3 is optional and adds a new warning to catch the issue in patch 2.

Rick Edgecombe (3):
  x86/shstk: Handle vfork clone failure correctly
  x86/shstk: Remove useless clone error handling
  x86/shstk: Add warning for shadow stack double unmap

 arch/x86/include/asm/mmu_context.h |  3 +--
 arch/x86/kernel/process.c          |  7 -------
 arch/x86/kernel/shstk.c            | 33 ++++++++++++++++++++++++++++--
 3 files changed, 32 insertions(+), 11 deletions(-)

-- 
2.34.1