From: "Iván Ezequiel Rodriguez" <ivanrwcm25@gmail.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org
Cc: "H . Peter Anvin" <hpa@zytor.com>,
"Shuah Khan" <shuah@kernel.org>,
"Christian Brauner" <brauner@kernel.org>,
"Rick Edgecombe" <rick.p.edgecombe@intel.com>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
"Iván Ezequiel Rodriguez" <ivanrwcm25@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH v2 1/2] x86/shstk: free shadow stack when copy_thread() fails
Date: Thu, 22 Oct 2026 19:17:20 -0300 [thread overview]
Message-ID: <20261022221722.619233-2-ivanrwcm25@gmail.com> (raw)
In-Reply-To: <20261022221722.619233-1-ivanrwcm25@gmail.com>
copy_thread() maps a shadow stack for a CLONE_VM child and can still
fail in set_new_tls(). That error returns through bad_fork_cleanup_io,
which does not call exit_thread(). bad_fork_cleanup_thread does, but
only after copy_thread() has returned 0.
commit 748c90c69336 ("x86/shstk: Remove useless clone error handling")
removed the shstk_free() on this path, assuming exit_thread() would
run. It does not. Each rejected clone leaves one shadow-stack VMA in
the parent's mm until the mm dies: one map_count slot, pages not
populated. The size follows the clone stack, or RLIMIT_STACK when
that size is zero.
Free only after set_new_tls() fails, via a dedicated cleanup label.
Nest the TLS error check under CLONE_SETTLS so the successful path
returns 0 explicitly. The allocation error returns earlier, while
the child's base still aliases the parent. shstk_free() ignores a
cleared base and a different mm, so CLONE_VFORK and !CLONE_VM stay
no-ops. The exit_thread() path is left alone, so the double unmap
that commit avoided does not come back. The io bitmap is still
shared only when TLS setup succeeds.
Tested with user shadow stack enabled, on one config with and without
this change. 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 VMA count was unchanged and call/return on the parent still used
the original shadow stack.
Fixes: 748c90c69336 ("x86/shstk: Remove useless clone error handling")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>
---
arch/x86/kernel/process.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 346c438ac880..451594fa5481 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -176,7 +176,7 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
struct fork_frame *fork_frame;
struct pt_regs *childregs;
unsigned long new_ssp;
- int ret = 0;
+ int ret;
childregs = task_pt_regs(p);
fork_frame = container_of(childregs, struct fork_frame, regs);
@@ -263,12 +263,19 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
}
/* Set a new TLS for the child thread? */
- if (clone_flags & CLONE_SETTLS)
+ if (clone_flags & CLONE_SETTLS) {
ret = set_new_tls(p, tls);
+ if (ret)
+ goto shstk_free;
+ }
- if (!ret && unlikely(test_tsk_thread_flag(current, TIF_IO_BITMAP)))
+ if (unlikely(test_tsk_thread_flag(current, TIF_IO_BITMAP)))
io_bitmap_share(p);
+ return 0;
+
+shstk_free:
+ shstk_free(p);
return ret;
}
--
2.43.0
next prev parent reply other threads:[~2026-10-22 22:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 2:31 [PATCH 0/2] x86/shstk: don't leak a shadow stack when clone TLS fails Iván Ezequiel Rodriguez
2026-10-15 2:31 ` [PATCH 1/2] x86/shstk: free shadow stack when copy_thread() fails Iván Ezequiel Rodriguez
2026-10-21 19:26 ` Edgecombe, Rick P
2026-10-15 2:31 ` [PATCH 2/2] selftests/x86: shadow stack must survive a bad TLS Iván Ezequiel Rodriguez
2026-10-22 22:17 ` [PATCH v2 0/2] x86/shstk: don't leak a shadow stack when clone TLS fails Iván Ezequiel Rodriguez
2026-10-22 22:17 ` Iván Ezequiel Rodriguez [this message]
2026-10-22 22:17 ` [PATCH v2 2/2] selftests/x86: shadow stack must survive a bad TLS Iván Ezequiel Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261022221722.619233-2-ivanrwcm25@gmail.com \
--to=ivanrwcm25@gmail.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®