seccomp: always propagate NO_NEW_PRIVS on tsync

commit 103502a3 upstream.

Before this patch, a process with some permissive seccomp filter
that was applied by root without NO_NEW_PRIVS was able to add
more filters to itself without setting NO_NEW_PRIVS by setting
the new filter from a throwaway thread with NO_NEW_PRIVS.
Signed-off-by: Jann Horn <jann@thejh.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

kernel/seccomp.c

@@ -317,13 +317,7 @@ static inline void seccomp_sync_threads(void)
 		put_seccomp_filter(thread);
 		smp_store_release(&thread->seccomp.filter,
 				  caller->seccomp.filter);
-		/*
-		 * Opt the other thread into seccomp if needed.
-		 * As threads are considered to be trust-realm
-		 * equivalent (see ptrace_may_access), it is safe to
-		 * allow one thread to transition the other.
-		 */
-		if (thread->seccomp.mode == SECCOMP_MODE_DISABLED) {
+
 		/*
 		 * Don't let an unprivileged task work around
 		 * the no_new_privs restriction by creating
@@ -333,9 +327,15 @@ static inline void seccomp_sync_threads(void)
 		if (task_no_new_privs(caller))
 			task_set_no_new_privs(thread);
 
+		/*
+		 * Opt the other thread into seccomp if needed.
+		 * As threads are considered to be trust-realm
+		 * equivalent (see ptrace_may_access), it is safe to
+		 * allow one thread to transition the other.
+		 */
+		if (thread->seccomp.mode == SECCOMP_MODE_DISABLED)
 			seccomp_assign_mode(thread, SECCOMP_MODE_FILTER);
 	}
-	}
 }
 
 /**