From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 944052C0F8C for ; Sat, 4 Jul 2026 23:19:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783207153; cv=none; b=AnpQPr2N8jZnGtJT9IBQKGhkFe5IL9I2GYHy2+FDr+Uqbu41pIbTOQrZUWC+7Fh27+hTfGkuqdJkaMagZKr63QReLLVNPaqnZaOyfvUTRYf+RxLe1Jlii9XPRkvsCXkiDkCrswtoA/wAWWSdc0pIA6Xd+UM9Fqw8TIqs+rLMl6c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783207153; c=relaxed/simple; bh=8+kcWJlcEhIwOITpC65eoslayFO4cJRsGBfAPyhzz1w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PIcsnyxXyXWQwYZNwMu/4uVxJh8EEL++M6PzNoCGn/4CmDDWp1BSWGtl/a8ocUSuJbifa5IqsdeJpzR0HCS+zkwBedD+zMOZLlwH0nLOV6PyMSuSW6Dj/hCBl0JlIMIPFUSFAjVLdXI9kVLw3SgF6hMRuo5i4e3BuGpeXGYF6bY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=S8rDhFGr; arc=none smtp.client-ip=209.85.214.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S8rDhFGr" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2cad225673bso14400025ad.3 for ; Sat, 04 Jul 2026 16:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783207150; x=1783811950; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ByQ2HFYB3jNvuqPy2QTHv1A9/cHA6wxh+uKXzmjpR+o=; b=S8rDhFGrqwzog+liOedu3sWBFlLd7lxsHE+cFxnUL4LsC82JtoMK9lZh200ohETgEK NqpJKq/6/If0P7W1JQzpzvY4X7Bq3hs0pqwvXNLB/S5A53LEya/E06wE3lQk4Rhg0uCa BKAkCw0PEErNtd9v1089Inz+T49+uBIz5UlFw3/fEH3xQuUci83+OqLdudmLz+w9RvjA LZ5J052Q+T/9AY/z+OhMle5DjgrsKjN8ccGyHx/xYwnQ7WASTtYOcW47PcmONeBTWnfD 76ZrrAv2/KD0WdhLy7UJSmHmi/wS/bfvH61Mfjg2WKoTM1oP7M0KGuEbmRm2y8hwYgtl COxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783207150; x=1783811950; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ByQ2HFYB3jNvuqPy2QTHv1A9/cHA6wxh+uKXzmjpR+o=; b=fphb1VLerCm9ODS+0qb0N1AYS+WvbLyXe5oEERqADFBqK4y+06JcjpLvJb9mZ8cIOY wUD27bGL0noIG+e6zh85adhYgmuOLfgLRvp3NgEykSQOviDL2j/5zyOQbX5Cnif6WZgL ZV36p7Ur/x3RtR/gnpkXhtYpfkfVymO7gf7jY67Iati2rze9T0CsTKGMnN9TFkMcNfnG o5Q6bq1FZsqDYNWFN6oioA5UIKgJDSw2RWtb3z5atUmGbL5SMgdziqHlCbKDxNiyY0W5 T0HWibL9K7x2va1FGPvCixjBiz/SZfKHHqQn8OoB6D0/9+ptv2CAP+vvTRhl/wqn2eqX 7j8w== X-Forwarded-Encrypted: i=1; AHgh+Rr43/oOC5+OH041dVxDVtPGQx8JIgMR0dsLf8Qsv5J3Fbb97xThNIVXMto5rC1aN65D1xOuS+y0oPs2ewQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwCnrKPJqmImR9vDhFfdEC6LFucJouP5jahgdevQoFy+jHhv7VR VgofVKMVUcuW2T4x8n+asIHP5xo3eDF2olXq36KyHWkTYG9GD/bjnZsu X-Gm-Gg: AfdE7ckEBJ6PAjQth/iJj8EXdqW+8oHVNzLwVp/nSLL79Z+wpzHj8lJSlTz2XUQpgMU JMROEgGjY9akiGl7wtmhRJ3ftv2osIZCp3TnyEaxhrA2kGoLP8C81CQE+SR1tg3ZHTem7AU3zMQ ZgtPcM1ebV0FWiQGM/dbF4NJwCngMEGnRwYk8+NsSYcIifdrylX/t/rXyUrrZZ7oVwQeus1Ptwv n0dgHNmAaIhF6UwAthPsHrX9DNOKDeMvWKTCHnEfheUaYPijyOOw6rGOoltxvj5HVDvmiZ6oVuQ 8ZywdLDt1O6tRd9KzWUKaARFJ3HwO+7TuUSsAX47dpVjMcTKlN8MknQNxt9sd6A4oKzvieoNjCQ AZseytb2cTiZplWczqme7Z66ZO1cUd5+6M7KMA9J7veeDrJM76JfPOngrLVT5Upb1wWqNm/+9Y1 ucLEXYcCjd4SjIx2YJ/FHG2XnWYXuDXvudunZjDnrqTuYAOThuluasSzBNrhbX X-Received: by 2002:a17:902:f706:b0:2c9:ceb9:865b with SMTP id d9443c01a7336-2cbb9e2426fmr44675575ad.21.1783207149897; Sat, 04 Jul 2026 16:19:09 -0700 (PDT) Received: from pop-os.. ([2601:647:6802:dbc0:55ba:96cc:892f:32d7]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cad776589fsm27088215ad.43.2026.07.04.16.19.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jul 2026 16:19:09 -0700 (PDT) From: Cong Wang To: Andy Lutomirski Cc: Kees Cook , linux-kernel@vger.kernel.org, Will Drewry , Christian Brauner , Andrew Morton , linux-mm@kvack.org, Cong Wang Subject: [PATCH v5 5/7] seccomp: re-validate a redirected syscall against outer filters Date: Sat, 4 Jul 2026 16:18:29 -0700 Message-ID: <20260704231831.354543-6-xiyou.wangcong@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260704231831.354543-1-xiyou.wangcong@gmail.com> References: <20260704231831.354543-1-xiyou.wangcong@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Cong Wang Stacked seccomp filters compose by seccomp_run_filters() taking the most restrictive verdict over one evaluation of a single seccomp_data. That assumes the syscall the filters voted on is the syscall that runs. SECCOMP_IOCTL_NOTIF_SEND_REDIRECT breaks the assumption: a USER_NOTIF filter's supervisor rewrites the argument registers and the syscall resumes via FLAG_CONTINUE without the stack being re-consulted. So an inner, container-installed filter can redirect a syscall into a form an outer filter would have blocked. Close the hole by re-evaluating after a redirect. Starting at the filter outer to the one that notified (match->prev), seccomp_run_filters_seq() walks toward the root, judging the substituted syscall one filter at a time and stopping at the first that does not allow it. An outer filter may ERRNO/KILL/TRAP/TRACE (terminal) or run its own USER_NOTIF; if that notifier redirects again or resumes with a bare FLAG_CONTINUE, the syscall still runs, so the walk continues from its ->prev. The walk is strictly outward, so an inner filter is never reconsulted (no re-notify loop), and iterative (goto, not recursion) so a deep chain cannot exhaust the kernel stack. Only a redirect starts the walk; the first pass and the allow-cache are unchanged, so nothing changes for existing, non-redirect users. Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Cong Wang --- kernel/seccomp.c | 100 ++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 95 insertions(+), 5 deletions(-) diff --git a/kernel/seccomp.c b/kernel/seccomp.c index c5a01ae097d1..7e572bb34993 100644 --- a/kernel/seccomp.c +++ b/kernel/seccomp.c @@ -94,6 +94,13 @@ struct seccomp_knotif { long val; u32 flags; + /* + * Set by SEND_REDIRECT: the reply rewrote the syscall's registers, + * so on resume the syscall must be re-evaluated against the filters + * outer to the one that notified (see __seccomp_filter()). + */ + bool redirect; + /* * Signals when this has changed states, such as the listener * dying, a new seccomp addfd message, or changing to REPLIED @@ -1181,10 +1188,12 @@ static bool should_sleep_killable(struct seccomp_filter *match, static int seccomp_do_user_notification(int this_syscall, struct seccomp_filter *match, - const struct seccomp_data *sd) + const struct seccomp_data *sd, + bool *redirected) { int err; u32 flags = 0; + bool redirect = false; long ret = 0; struct seccomp_knotif n = {}; struct seccomp_kaddfd *addfd, *tmp; @@ -1241,6 +1250,7 @@ static int seccomp_do_user_notification(int this_syscall, ret = n.val; err = n.error; flags = n.flags; + redirect = n.redirect; interrupted: /* If there were any pending addfd calls, clear them out */ @@ -1267,19 +1277,44 @@ static int seccomp_do_user_notification(int this_syscall, mutex_unlock(&match->notify_lock); /* Userspace requests to continue the syscall. */ - if (flags & SECCOMP_USER_NOTIF_FLAG_CONTINUE) + if (flags & SECCOMP_USER_NOTIF_FLAG_CONTINUE) { + *redirected = redirect; return 0; + } syscall_set_return_value(current, current_pt_regs(), err, ret); return -1; } +static u32 seccomp_run_filters_seq(const struct seccomp_data *sd, + struct seccomp_filter **match, + struct seccomp_filter *f, + int this_syscall) +{ + for (; f; f = f->prev) { + u32 cur_ret = bpf_prog_run_pin_on_cpu(f->prog, sd); + u32 action = ACTION_ONLY(cur_ret); + + if (action == SECCOMP_RET_ALLOW) + continue; + /* LOG does not block the syscall; record it and continue. */ + if (action == SECCOMP_RET_LOG) { + seccomp_log(this_syscall, 0, action, true); + continue; + } + *match = f; + return cur_ret; + } + return SECCOMP_RET_ALLOW; +} + static int __seccomp_filter(int this_syscall, const bool recheck_after_trace) { u32 filter_ret, action; struct seccomp_data sd; struct seccomp_filter *match = NULL; + bool in_walk = false; int data; /* @@ -1291,6 +1326,8 @@ static int __seccomp_filter(int this_syscall, const bool recheck_after_trace) populate_seccomp_data(&sd); filter_ret = seccomp_run_filters(&sd, &match); + +eval: data = filter_ret & SECCOMP_RET_DATA; action = filter_ret & SECCOMP_RET_ACTION_FULL; @@ -1342,6 +1379,18 @@ static int __seccomp_filter(int this_syscall, const bool recheck_after_trace) if (this_syscall < 0) goto skip; + /* + * During a post-redirect outward walk, TRACE is terminal: the + * tracer has handled the call and, like the other blocking + * actions, the walk consults no further filters. Do not run the + * full-stack recheck below: it restarts from the innermost + * filter and would reconsult (and re-notify) the inner filter + * that redirected, breaking the walk's monotonic-outward + * guarantee. + */ + if (in_walk) + return 0; + /* * Recheck the syscall, since it may have changed. This * intentionally uses a NULL struct seccomp_data to force @@ -1353,11 +1402,51 @@ static int __seccomp_filter(int this_syscall, const bool recheck_after_trace) return 0; - case SECCOMP_RET_USER_NOTIF: - if (seccomp_do_user_notification(this_syscall, match, &sd)) + case SECCOMP_RET_USER_NOTIF: { + struct seccomp_filter *outer; + bool redirected = false; + + if (seccomp_do_user_notification(this_syscall, match, &sd, + &redirected)) goto skip; - return 0; + /* + * Continue the outward walk only when the syscall still runs + * and there is an outer filter left to judge it. That holds for + * a redirect, and for a plain FLAG_CONTINUE (resume, no + * redirect) reached during the walk: either way the call must + * keep being offered to the remaining outer filters, or this + * notifier's reply would let it slip past a stricter filter + * further out. A redirect by the outermost filter (no + * match->prev) has no outer filter to re-validate against. + */ + if (!match->prev || !(redirected || in_walk)) + return 0; + + if (redirected) { + /* + * The notifier rewrote the registers. Reload the + * seccomp_data so the outer filters judge the + * substituted syscall; a plain resume leaves the + * registers (and thus the current sd) unchanged. The + * walk is strictly outward, so a notifier can never + * re-notify on its own redirect. + */ + populate_seccomp_data(&sd); + this_syscall = sd.nr; + if (this_syscall < 0) + return 0; + in_walk = true; + } + + outer = match->prev; + match = NULL; + filter_ret = seccomp_run_filters_seq(&sd, &match, outer, + this_syscall); + if (!match) + return 0; + goto eval; + } case SECCOMP_RET_LOG: seccomp_log(this_syscall, 0, action, true); @@ -2201,6 +2290,7 @@ static long seccomp_notify_send_redirect(struct seccomp_filter *filter, goto out_unlock_free; } + knotif->redirect = true; knotif->state = SECCOMP_NOTIFY_REPLIED; knotif->error = 0; knotif->val = 0; -- 2.43.0