Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2249110imm; Thu, 27 Sep 2018 09:40:30 -0700 (PDT) X-Google-Smtp-Source: ACcGV63DvotCZU9u/orAaLUVPVeGNe+fC82zAl2tuT0WQo93pTLv1Qxb3yFbTMe3VG6kgPVtQQEV X-Received: by 2002:a63:a40a:: with SMTP id c10-v6mr11319117pgf.140.1538066430323; Thu, 27 Sep 2018 09:40:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538066430; cv=none; d=google.com; s=arc-20160816; b=ej2yeCsk9rDxLmHPuFNTagHyyl05cVfnNlgXd5DbcGhgTPEhQjjDgvxmIadtOxumoY I4Kg9bjqA3BX4ghmXDS4Dg4jad9DhkuVhWpfFcSuComY76QAz8OBprFOf2tzqvRIO9Ej YA5++bMYLrkdvhRn2juKH8TipsFVKb4CXrVQlplsSMAMlXhXIALW1sYqx2kTI7ZheQIs fUEHb6SL5+kla29H3W2aUiwdZMw0sAMUV8ZZfz5gUVpPxBym3DnT3gC2x9L9W3UeqsdB iFuRDJLg7P/Ivg0r8s/zKG9QYWbwvSbU8BcpTkxr5gRqugbeCfQKj2hyMuNmRZT7jEdx GNyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=W+NSFHXC1p7u5iKRZ3HUB2PYuPEIC+MQP01YmK7YI6w=; b=AJyOMBtRckV+rVtmebtbB/G+iSmB6RKgcQ6+MlblMKthSAZJp3xbXLtA7QhJPoTotb vc3RuMnTmY5YVGHkDyVsjMyOeLZBxlPAnrwxDkb3OpaeJlhqlVuMXpjsMYyc2zbwvIh6 t44It/mvHkmXoWemKqVaIdo7o7khZT2uTsn0bKA5mYwNnQ42jQ4HEHFlengzu2L4dpuA 0qAB2Gu29Vv1YkNqbMkLSra4N+KQkn/oDv9a4sm8jzwHjuVwPRJYQMIz9W1t9WFuZ7t5 rJFb2caU1NcOvcg77IVsxd5gnEhOQzfw7epxCxlEP+wLvE3pQtjSO7qkziIuLZCIQFSy U64w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="KZ7X4bM/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d7-v6si2421413pln.68.2018.09.27.09.40.13; Thu, 27 Sep 2018 09:40:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="KZ7X4bM/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728379AbeI0W6g (ORCPT + 99 others); Thu, 27 Sep 2018 18:58:36 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:44630 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727320AbeI0W6f (ORCPT ); Thu, 27 Sep 2018 18:58:35 -0400 Received: by mail-ot1-f68.google.com with SMTP id 36-v6so3164721oth.11 for ; Thu, 27 Sep 2018 09:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W+NSFHXC1p7u5iKRZ3HUB2PYuPEIC+MQP01YmK7YI6w=; b=KZ7X4bM/YsPzjj35WqOrg2UGCcJ4bckA/Y4vHxEKNxSdRx/XcW5qTohQifYPa/gBJt DdrlJDiioYy6DHBq6D9lXk0VIKTLa8uEqWwoVYaeVLY8A8ByxkfsyFwBnG8J/2dE0Vzw 34FP9Q4BJ8O4tWpXUy3F2PDPvBigCMBw6AWlXlFkaL72dOBDMbWh8W+/1/OoglJbHI1s MIpAm6YSy2Xp9fF4V6313h3Yjghc+9p96FGI29m+uSsCDdkWkfW99uyCDeOO+smK6E+s 0vnEsSjGX1xINcs+Z9hJ3SbDRO1jPj/n8efAnVcdv/wFmvH+FwAMSi7+MSIdgf+rcm5C WV0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W+NSFHXC1p7u5iKRZ3HUB2PYuPEIC+MQP01YmK7YI6w=; b=hVMGAi9XrqMIJVIOX4NaMn+/ccfq0MtRl1W21z7757jE4bJ4vtkMDvLn3oIAhDoShO xrCc8OIBivGHdIZQShALUvBEbROstAObbgf4jkoeUDncU+gSlZtHLk4i7mLHcV9n7vsY JaemmY0G+T8NmkIuTJOX2DArb/4j4tGyPOPYq8UUYGvQ1LJj7xFcZo7hEoey2w9twDUC rQn7qVIC1rg38XTHt5IQ8T835w7fbUlGkdojts3thGV1DNQZGY8hzc90akm6AeE8oU82 4B5R7efthOcsodoPdIEv9bZ5vJKkyR2gBU8mn5GgBtlC7erFSNaBCkrRjs/QhXTu+cKC Tvfw== X-Gm-Message-State: ABuFfoj1q1844c0RBf0DMu7i0I3cp22wY0AyKh/X/7wEAwib5Ev/Ic1g uGEHq8iEstEn4TewUo210nN9arWGJ7+VvUsNLmLQpg== X-Received: by 2002:a9d:4716:: with SMTP id a22-v6mr7853743otf.242.1538066369286; Thu, 27 Sep 2018 09:39:29 -0700 (PDT) MIME-Version: 1.0 References: <20180927151119.9989-1-tycho@tycho.ws> <20180927151119.9989-6-tycho@tycho.ws> In-Reply-To: <20180927151119.9989-6-tycho@tycho.ws> From: Jann Horn Date: Thu, 27 Sep 2018 18:39:02 +0200 Message-ID: Subject: Re: [PATCH v7 5/6] seccomp: add a way to pass FDs via a notification fd To: Tycho Andersen Cc: Kees Cook , kernel list , containers@lists.linux-foundation.org, Linux API , Andy Lutomirski , Oleg Nesterov , "Eric W. Biederman" , "Serge E. Hallyn" , Christian Brauner , Tyler Hicks , suda.akihiro@lab.ntt.co.jp, linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen wrote: > This patch adds a way to insert FDs into the tracee's process (also > close/overwrite fds for the tracee). This functionality is necessary to > mock things like socketpair() or dup2() or similar, but since it depends on > external (vfs) patches, I've left it as a separate patch as before so the > core functionality can still be merged while we argue about this. Except > this time it doesn't add any ugliness to the API :) [...] > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > index 17685803a2af..07a05ad59731 100644 > --- a/kernel/seccomp.c > +++ b/kernel/seccomp.c > @@ -41,6 +41,8 @@ > #include > #include > #include > +#include > +#include > > enum notify_state { > SECCOMP_NOTIFY_INIT, > @@ -1684,6 +1686,56 @@ static long seccomp_notify_id_valid(struct seccomp_filter *filter, > return ret; > } > > +static long seccomp_notify_put_fd(struct seccomp_filter *filter, > + unsigned long arg) > +{ > + struct seccomp_notif_put_fd req; > + void __user *buf = (void __user *)arg; > + struct seccomp_knotif *knotif = NULL; > + long ret; > + > + if (copy_from_user(&req, buf, sizeof(req))) > + return -EFAULT; > + > + if (req.fd < 0 && req.to_replace < 0) > + return -EINVAL; > + > + ret = mutex_lock_interruptible(&filter->notify_lock); > + if (ret < 0) > + return ret; > + > + ret = -ENOENT; > + list_for_each_entry(knotif, &filter->notif->notifications, list) { > + struct file *file = NULL; > + > + if (knotif->id != req.id) > + continue; > + > + if (req.fd >= 0) > + file = fget(req.fd); So here we take a reference on `file`. > + if (req.to_replace >= 0) { > + ret = replace_fd_task(knotif->task, req.to_replace, > + file, req.fd_flags); Then here we try to place the file in knotif->task's file descriptor table. This can either fail (e.g. due to exceeded rlimit), in which case nothing happens, or it can do do_dup2(), which first takes an extra reference to the file, then places it in the task's fd table. Either way, afterwards, we still hold a reference to the file. > + } else { > + unsigned long max_files; > + > + max_files = task_rlimit(knotif->task, RLIMIT_NOFILE); > + ret = __alloc_fd(knotif->task->files, 0, max_files, > + req.fd_flags); > + if (ret < 0) > + break; If we bail out here, we still hold a reference to `file`. Suggestion: Change this to "if (ret >= 0) {" and make the following code conditional instead of breaking. > + __fd_install(knotif->task->files, ret, file); But if we reach this point, __fd_install() consumes the file pointer, so `file` is a dangling pointer now. Suggestion: Add "break;" here. > + } Suggestion: Add "if (file != NULL) fput(file);" here. > + break; > + } > + > + mutex_unlock(&filter->notify_lock); > + return ret; > +}