All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Willy Tarreau <w@1wt.eu>, Mikulas Patocka <mpatocka@redhat.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	linux-kernel@vger.kernel.org, Eric Biggers <ebiggers@google.com>,
	stable@vger.kernel.org
Subject: [PATCH 3/7] pipe: actually allow root to exceed the pipe buffer limits
Date: Sun,  7 Jan 2018 21:35:38 -0800	[thread overview]
Message-ID: <20180108053542.6472-4-ebiggers3@gmail.com> (raw)
In-Reply-To: <20180108053542.6472-1-ebiggers3@gmail.com>

From: Eric Biggers <ebiggers@google.com>

pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply
to unprivileged users, as documented in both Documentation/sysctl/fs.txt
and the pipe(7) man page.

However, the capabilities are actually only checked when increasing a
pipe's size using F_SETPIPE_SZ, not when creating a new pipe.
Therefore, if pipe-user-pages-hard has been set, the root user can run
into it and be unable to create pipes.  Similarly, if
pipe-user-pages-soft has been set, the root user can run into it and
have their pipes limited to 1 page each.

Fix this by allowing the privileged override in both cases.

Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 fs/pipe.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/fs/pipe.c b/fs/pipe.c
index d0dec5e7ef33..847ecc388820 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -613,6 +613,11 @@ static bool too_many_pipe_buffers_hard(unsigned long user_bufs)
 	return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
 }
 
+static bool is_unprivileged_user(void)
+{
+	return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN);
+}
+
 struct pipe_inode_info *alloc_pipe_info(void)
 {
 	struct pipe_inode_info *pipe;
@@ -629,12 +634,12 @@ struct pipe_inode_info *alloc_pipe_info(void)
 
 	user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
 
-	if (too_many_pipe_buffers_soft(user_bufs)) {
+	if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) {
 		user_bufs = account_pipe_buffers(user, pipe_bufs, 1);
 		pipe_bufs = 1;
 	}
 
-	if (too_many_pipe_buffers_hard(user_bufs))
+	if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user())
 		goto out_revert_acct;
 
 	pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
@@ -1065,7 +1070,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 	if (nr_pages > pipe->buffers &&
 			(too_many_pipe_buffers_hard(user_bufs) ||
 			 too_many_pipe_buffers_soft(user_bufs)) &&
-			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
+			is_unprivileged_user()) {
 		ret = -EPERM;
 		goto out_revert_acct;
 	}
-- 
2.15.1

  parent reply	other threads:[~2018-01-08  5:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08  5:35 [PATCH 0/7] pipe: buffer limits fixes and cleanups Eric Biggers
2018-01-08  5:35 ` [PATCH 1/7] pipe, sysctl: drop 'min' parameter from pipe-max-size converter Eric Biggers
2018-01-09 22:20   ` Kees Cook
2018-01-10  2:29     ` Eric Biggers
2018-01-10 17:30       ` Kees Cook
2018-01-08  5:35 ` [PATCH 2/7] pipe, sysctl: remove pipe_proc_fn() Eric Biggers
2018-01-08  5:35 ` Eric Biggers [this message]
2018-01-09 22:23   ` [PATCH 3/7] pipe: actually allow root to exceed the pipe buffer limits Kees Cook
2018-01-10  2:34     ` Eric Biggers
2018-01-08  5:35 ` [PATCH 4/7] pipe: fix off-by-one error when checking " Eric Biggers
2018-01-08  6:42   ` Willy Tarreau
2018-01-08  5:35 ` [PATCH 5/7] pipe: reject F_SETPIPE_SZ with size over UINT_MAX Eric Biggers
2018-01-09 22:24   ` Kees Cook
2018-01-08  5:35 ` [PATCH 6/7] pipe: simplify round_pipe_size() Eric Biggers
2018-01-09 22:27   ` Kees Cook
2018-01-10  2:52     ` Eric Biggers
2018-01-10  3:13       ` Kees Cook
2018-01-08  5:35 ` [PATCH 7/7] pipe: read buffer limits atomically Eric Biggers
2018-01-09 22:27   ` Kees Cook

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=20180108053542.6472-4-ebiggers3@gmail.com \
    --to=ebiggers3@gmail.com \
    --cc=ebiggers@google.com \
    --cc=joe.lawrence@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=mtk.manpages@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=w@1wt.eu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.