copy_thread() maps a shadow stack and set_new_tls() can still fail.
That error goes to bad_fork_cleanup_io and skips exit_thread().
bad_fork_cleanup_thread calls exit_thread() only after copy_thread()
has returned 0.
commit 748c90c69336 ("x86/shstk: Remove useless clone error handling")
removed the shstk_free() on the set_new_tls() failure. Restoring it
only there puts back the single free. The allocation-error return
still aliases the parent, and the exit_thread() path is left alone,
so the double unmap that commit avoided does not come back.
The selftest assumes /proc is mounted. A clone3() with a valid TLS
must succeed before EPERM counts as the TLS failure. No CPUID support,
no kernel support, or a locked feature skips the test. Any other
ARCH_SHSTK_ENABLE error fails it.
Sixteen clone3() calls with CLONE_VM|CLONE_SETTLS and an out-of-range
TLS leaked 16 shadow-stack VMAs without the fix. With it, the count
stayed unchanged and call/return on the parent still used the
original shadow stack. Tested with user shadow stack on the host and
in a one-vCPU KVM guest (-cpu host), same configuration with and
without the fix.
The diagnosis and the selftest were drafted with Grok 4.7.
Iván Ezequiel Rodriguez (2):
x86/shstk: free shadow stack when copy_thread() fails
selftests/x86: shadow stack must survive a bad TLS
arch/x86/kernel/process.c | 12 +-
tools/testing/selftests/x86/Makefile | 3 +-
tools/testing/selftests/x86/shstk_clone_tls.c | 364 ++++++++++++++++++
3 files changed, 376 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/x86/shstk_clone_tls.c
--
2.43.0
