linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* [PATCH 3.16 202/410] pipe: fix limit checking in pipe_set_size()
  @ 2018-06-07 14:05 50% ` Ben Hutchings
  0 siblings, 0 replies; 13+ results
From: Ben Hutchings @ 2018-06-07 14:05 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: akpm, Jens Axboe, Willy Tarreau, Al Viro, socketpair,
	Michael Kerrisk (man-pages),
	Tetsuo Handa, Vegard Nossum, Linus Torvalds

3.16.57-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>

commit b0b91d18e2e97b741b294af9333824ecc3fadfd8 upstream.

The limit checking in pipe_set_size() (used by fcntl(F_SETPIPE_SZ))
has the following problems:

(1) When increasing the pipe capacity, the checks against the limits in
    /proc/sys/fs/pipe-user-pages-{soft,hard} are made against existing
    consumption, and exclude the memory required for the increased pipe
    capacity. The new increase in pipe capacity can then push the total
    memory used by the user for pipes (possibly far) over a limit. This
    can also trigger the problem described next.

(2) The limit checks are performed even when the new pipe capacity is
    less than the existing pipe capacity. This can lead to problems if a
    user sets a large pipe capacity, and then the limits are lowered,
    with the result that the user will no longer be able to decrease the
    pipe capacity.

(3) As currently implemented, accounting and checking against the
    limits is done as follows:

    (a) Test whether the user has exceeded the limit.
    (b) Make new pipe buffer allocation.
    (c) Account new allocation against the limits.

    This is racey. Multiple processes may pass point (a)
    simultaneously, and then allocate pipe buffers that are accounted
    for only in step (c).  The race means that the user's pipe buffer
    allocation could be pushed over the limit (by an arbitrary amount,
    depending on how unlucky we were in the race). [Thanks to Vegard
    Nossum for spotting this point, which I had missed.]

This patch addresses the above problems as follows:

* Perform checks against the limits only when increasing a pipe's
  capacity; an unprivileged user can always decrease a pipe's capacity.
* Alter the checks against limits to include the memory required for
  the new pipe capacity.
* Re-order the accounting step so that it precedes the buffer
  allocation. If the accounting step determines that a limit has
  been reached, revert the accounting and cause the operation to fail.

The program below can be used to demonstrate problems 1 and 2, and the
effect of the fix. The program takes one or more command-line arguments.
The first argument specifies the number of pipes that the program should
create. The remaining arguments are, alternately, pipe capacities that
should be set using fcntl(F_SETPIPE_SZ), and sleep intervals (in
seconds) between the fcntl() operations. (The sleep intervals allow the
possibility to change the limits between fcntl() operations.)

Problem 1
=========

Using the test program on an unpatched kernel, we first set some
limits:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard    # 40.96 MB

Then show that we can set a pipe with capacity (100MB) that is
over the hard limit

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            F_SETPIPE_SZ returned 134217728

Now set the capacity to 100MB twice. The second call fails (which is
probably surprising to most users, since it seems like a no-op):

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000 0 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            F_SETPIPE_SZ returned 134217728
        Loop 2: set pipe capacity to 100000000 bytes
            Loop 2, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

With a patched kernel, setting a capacity over the limit fails at the
first attempt:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard
    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            Loop 1, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

There is a small chance that the change to fix this problem could
break user-space, since there are cases where fcntl(F_SETPIPE_SZ)
calls that previously succeeded might fail. However, the chances are
small, since (a) the pipe-user-pages-{soft,hard} limits are new (in
4.5), and the default soft/hard limits are high/unlimited.  Therefore,
it seems warranted to make these limits operate more precisely (and
behave more like what users probably expect).

Problem 2
=========

Running the test program on an unpatched kernel, we first set some limits:

    # getconf PAGESIZE
    4096
    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard    # 40.96 MB

Now perform two fcntl(F_SETPIPE_SZ) operations on a single pipe,
first setting a pipe capacity (10MB), sleeping for a few seconds,
during which time the hard limit is lowered, and then set pipe
capacity to a smaller amount (5MB):

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 10000000 15 5000000 &
    [1] 748
    # Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 10000000 bytes
            F_SETPIPE_SZ returned 16777216
            Sleeping 15 seconds

    # echo 1000 > /proc/sys/fs/pipe-user-pages-hard      # 4.096 MB
    #     Loop 2: set pipe capacity to 5000000 bytes
            Loop 2, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

In this case, the user should be able to lower the limit.

With a kernel that has the patch below, the second fcntl()
succeeds:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard
    # sudo -u mtk ./test_F_SETPIPE_SZ 1 10000000 15 5000000 &
    [1] 3215
    # Initial pipe capacity: 65536
    #     Loop 1: set pipe capacity to 10000000 bytes
            F_SETPIPE_SZ returned 16777216
            Sleeping 15 seconds

    # echo 1000 > /proc/sys/fs/pipe-user-pages-hard

    #     Loop 2: set pipe capacity to 5000000 bytes
            F_SETPIPE_SZ returned 8388608

8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---

/* test_F_SETPIPE_SZ.c

   (C) 2016, Michael Kerrisk; licensed under GNU GPL version 2 or later

   Test operation of fcntl(F_SETPIPE_SZ) for setting pipe capacity
   and interactions with limits defined by /proc/sys/fs/pipe-* files.
*/

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
    int (*pfd)[2];
    int npipes;
    int pcap, rcap;
    int j, p, s, stime, loop;

    if (argc < 2) {
        fprintf(stderr, "Usage: %s num-pipes "
                "[pipe-capacity sleep-time]...\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    npipes = atoi(argv[1]);

    pfd = calloc(npipes, sizeof (int [2]));
    if (pfd == NULL) {
        perror("calloc");
        exit(EXIT_FAILURE);
    }

    for (j = 0; j < npipes; j++) {
        if (pipe(pfd[j]) == -1) {
            fprintf(stderr, "Loop %d: pipe() failed: ", j);
            perror("pipe");
            exit(EXIT_FAILURE);
        }
    }

    printf("Initial pipe capacity: %d\n", fcntl(pfd[0][0], F_GETPIPE_SZ));

    for (j = 2; j < argc; j += 2 ) {
        loop = j / 2;
        pcap = atoi(argv[j]);
        printf("    Loop %d: set pipe capacity to %d bytes\n", loop, pcap);

        for (p = 0; p < npipes; p++) {
            s = fcntl(pfd[p][0], F_SETPIPE_SZ, pcap);
            if (s == -1) {
                fprintf(stderr, "        Loop %d, pipe %d: F_SETPIPE_SZ "
                        "failed: ", loop, p);
                perror("fcntl");
                exit(EXIT_FAILURE);
            }

            if (p == 0) {
                printf("        F_SETPIPE_SZ returned %d\n", s);
                rcap = s;
            } else {
                if (s != rcap) {
                    fprintf(stderr, "        Loop %d, pipe %d: F_SETPIPE_SZ "
                            "unexpected return: %d\n", loop, p, s);
                    exit(EXIT_FAILURE);
                }
            }

            stime = (j + 1 < argc) ? atoi(argv[j + 1]) : 0;
            if (stime > 0) {
                printf("        Sleeping %d seconds\n", stime);
                sleep(stime);
            }
        }
    }

    exit(EXIT_SUCCESS);
}

8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---

Patch history:

v2
   * Switch order of test in 'if' statement to avoid function call
      (to capability()) in normal path. [This is a fix to a preexisting
      wart in the code. Thanks to Willy Tarreau]
    * Perform (size > pipe_max_size) check before calling
      account_pipe_buffers().  [Thanks to Vegard Nossum]
      Quoting Vegard:

        The potential problem happens if the user passes a very large number
        which will overflow pipe->user->pipe_bufs.

        On 32-bit, sizeof(int) == sizeof(long), so if they pass arg = INT_MAX
        then round_pipe_size() returns INT_MAX. Although it's true that the
        accounting is done in terms of pages and not bytes, so you'd need on
        the order of (1 << 13) = 8192 processes hitting the limit at the same
        time in order to make it overflow, which seems a bit unlikely.

        (See https://lkml.org/lkml/2016/8/12/215 for another discussion on the
        limit checking)

Link: http://lkml.kernel.org/r/1e464945-536b-2420-798b-e77b9c7e8593@gmail.com
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reviewed-by: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: <socketpair@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Jens Axboe <axboe@fb.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 fs/pipe.c | 41 +++++++++++++++++++++++++++++++----------
 1 file changed, 31 insertions(+), 10 deletions(-)

--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -1013,6 +1013,7 @@ static long pipe_set_size(struct pipe_in
 {
 	struct pipe_buffer *bufs;
 	unsigned int size, nr_pages;
+	long ret = 0;
 
 	size = round_pipe_size(arg);
 	nr_pages = size >> PAGE_SHIFT;
@@ -1020,13 +1021,26 @@ static long pipe_set_size(struct pipe_in
 	if (!nr_pages)
 		return -EINVAL;
 
-	if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size)
+	/*
+	 * If trying to increase the pipe capacity, check that an
+	 * unprivileged user is not trying to exceed various limits
+	 * (soft limit check here, hard limit check just below).
+	 * Decreasing the pipe capacity is always permitted, even
+	 * if the user is currently over a limit.
+	 */
+	if (nr_pages > pipe->buffers &&
+			size > pipe_max_size && !capable(CAP_SYS_RESOURCE))
 		return -EPERM;
 
-	if ((too_many_pipe_buffers_hard(pipe->user) ||
-			too_many_pipe_buffers_soft(pipe->user)) &&
-			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
-		return -EPERM;
+	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
+
+	if (nr_pages > pipe->buffers &&
+			(too_many_pipe_buffers_hard(pipe->user) ||
+			 too_many_pipe_buffers_soft(pipe->user)) &&
+			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
+		ret = -EPERM;
+		goto out_revert_acct;
+	}
 
 	/*
 	 * We can shrink the pipe, if arg >= pipe->nrbufs. Since we don't
@@ -1034,12 +1048,16 @@ static long pipe_set_size(struct pipe_in
 	 * again like we would do for growing. If the pipe currently
 	 * contains more buffers than arg, then return busy.
 	 */
-	if (nr_pages < pipe->nrbufs)
-		return -EBUSY;
+	if (nr_pages < pipe->nrbufs) {
+		ret = -EBUSY;
+		goto out_revert_acct;
+	}
 
 	bufs = kcalloc(nr_pages, sizeof(*bufs), GFP_KERNEL | __GFP_NOWARN);
-	if (unlikely(!bufs))
-		return -ENOMEM;
+	if (unlikely(!bufs)) {
+		ret = -ENOMEM;
+		goto out_revert_acct;
+	}
 
 	/*
 	 * The pipe array wraps around, so just start the new one at zero
@@ -1062,12 +1080,15 @@ static long pipe_set_size(struct pipe_in
 			memcpy(bufs + head, pipe->bufs, tail * sizeof(struct pipe_buffer));
 	}
 
-	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
 	pipe->curbuf = 0;
 	kfree(pipe->bufs);
 	pipe->bufs = bufs;
 	pipe->buffers = nr_pages;
 	return nr_pages * PAGE_SIZE;
+
+out_revert_acct:
+	account_pipe_buffers(pipe->user, nr_pages, pipe->buffers);
+	return ret;
 }
 
 /*

^ permalink raw reply	[relevance 50%]

* [PATCH v2 4/8] pipe: fix limit checking in pipe_set_size()
       [not found]     <ef9ce203-6683-31b1-26dc-e0b823aba73e@gmail.com>
@ 2016-08-29  0:21 51% ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 13+ results
From: Michael Kerrisk (man-pages) @ 2016-08-29  0:21 UTC (permalink / raw)
  To: Andrew Morton
  Cc: mtk.manpages, Willy Tarreau, Vegard Nossum, socketpair,
	Tetsuo Handa, Jens Axboe, Al Viro, linux-api, linux-kernel

The limit checking in pipe_set_size() (used by fcntl(F_SETPIPE_SZ))
has the following problems:

(1) When increasing the pipe capacity, the checks against the limits in
    /proc/sys/fs/pipe-user-pages-{soft,hard} are made against existing
    consumption, and exclude the memory required for the increased pipe
    capacity. The new increase in pipe capacity can then push the total
    memory used by the user for pipes (possibly far) over a limit. This
    can also trigger the problem described next.

(2) The limit checks are performed even when the new pipe capacity is
    less than the existing pipe capacity. This can lead to problems if a
    user sets a large pipe capacity, and then the limits are lowered,
    with the result that the user will no longer be able to decrease the
    pipe capacity.

(3) As currently implemented, accounting and checking against the
    limits is done as follows:

    (a) Test whether the user has exceeded the limit.
    (b) Make new pipe buffer allocation.
    (c) Account new allocation against the limits.

    This is racey. Multiple processes may pass point (a)
    simultaneously, and then allocate pipe buffers that are accounted
    for only in step (c).  The race means that the user's pipe buffer
    allocation could be pushed over the limit (by an arbitrary amount,
    depending on how unlucky we were in the race). [Thanks to Vegard
    Nossum for spotting this point, which I had missed.]

This patch addresses the above problems as follows:

* Perform checks against the limits only when increasing a pipe's
  capacity; an unprivileged user can always decrease a pipe's capacity.
* Alter the checks against limits to include the memory required for
  the new pipe capacity.
* Re-order the accounting step so that it precedes the buffer
  allocation. If the accounting step determines that a limit has
  been reached, revert the accounting and cause the operation to fail.

The program below can be used to demonstrate problems 1 and 2, and the
effect of the fix. The program takes one or more command-line arguments.
The first argument specifies the number of pipes that the program should
create. The remaining arguments are, alternately, pipe capacities that
should be set using fcntl(F_SETPIPE_SZ), and sleep intervals (in
seconds) between the fcntl() operations. (The sleep intervals allow the
possibility to change the limits between fcntl() operations.)

Problem 1
=========

Using the test program on an unpatched kernel, we first set some
limits:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard    # 40.96 MB

Then show that we can set a pipe with capacity (100MB) that is
over the hard limit

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            F_SETPIPE_SZ returned 134217728

Now set the capacity to 100MB twice. The second call fails (which is
probably surprising to most users, since it seems like a no-op):

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000 0 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            F_SETPIPE_SZ returned 134217728
        Loop 2: set pipe capacity to 100000000 bytes
            Loop 2, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

With a patched kernel, setting a capacity over the limit fails at the
first attempt:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard
    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            Loop 1, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

There is a small chance that the change to fix this problem could
break user-space, since there are cases where fcntl(F_SETPIPE_SZ)
calls that previously succeeded might fail. However, the chances are
small, since (a) the pipe-user-pages-{soft,hard} limits are new (in
4.5), and the default soft/hard limits are high/unlimited.  Therefore,
it seems warranted to make these limits operate more precisely (and
behave more like what users probably expect).

Problem 2
=========

Running the test program on an unpatched kernel, we first set some limits:

    # getconf PAGESIZE
    4096
    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard    # 40.96 MB

Now perform two fcntl(F_SETPIPE_SZ) operations on a single pipe,
first setting a pipe capacity (10MB), sleeping for a few seconds,
during which time the hard limit is lowered, and then set pipe
capacity to a smaller amount (5MB):

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 10000000 15 5000000 &
    [1] 748
    # Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 10000000 bytes
            F_SETPIPE_SZ returned 16777216
            Sleeping 15 seconds

    # echo 1000 > /proc/sys/fs/pipe-user-pages-hard      # 4.096 MB
    #     Loop 2: set pipe capacity to 5000000 bytes
            Loop 2, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

In this case, the user should be able to lower the limit.

With a kernel that has the patch below, the second fcntl()
succeeds:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard
    # sudo -u mtk ./test_F_SETPIPE_SZ 1 10000000 15 5000000 &
    [1] 3215
    # Initial pipe capacity: 65536
    #     Loop 1: set pipe capacity to 10000000 bytes
            F_SETPIPE_SZ returned 16777216
            Sleeping 15 seconds

    # echo 1000 > /proc/sys/fs/pipe-user-pages-hard

    #     Loop 2: set pipe capacity to 5000000 bytes
            F_SETPIPE_SZ returned 8388608

8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---

/* test_F_SETPIPE_SZ.c

   (C) 2016, Michael Kerrisk; licensed under GNU GPL version 2 or later

   Test operation of fcntl(F_SETPIPE_SZ) for setting pipe capacity
   and interactions with limits defined by /proc/sys/fs/pipe-* files.
*/

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
    int (*pfd)[2];
    int npipes;
    int pcap, rcap;
    int j, p, s, stime, loop;

    if (argc < 2) {
        fprintf(stderr, "Usage: %s num-pipes "
                "[pipe-capacity sleep-time]...\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    npipes = atoi(argv[1]);

    pfd = calloc(npipes, sizeof (int [2]));
    if (pfd == NULL) {
        perror("calloc");
        exit(EXIT_FAILURE);
    }

    for (j = 0; j < npipes; j++) {
        if (pipe(pfd[j]) == -1) {
            fprintf(stderr, "Loop %d: pipe() failed: ", j);
            perror("pipe");
            exit(EXIT_FAILURE);
        }
    }

    printf("Initial pipe capacity: %d\n", fcntl(pfd[0][0], F_GETPIPE_SZ));

    for (j = 2; j < argc; j += 2 ) {
        loop = j / 2;
        pcap = atoi(argv[j]);
        printf("    Loop %d: set pipe capacity to %d bytes\n", loop, pcap);

        for (p = 0; p < npipes; p++) {
            s = fcntl(pfd[p][0], F_SETPIPE_SZ, pcap);
            if (s == -1) {
                fprintf(stderr, "        Loop %d, pipe %d: F_SETPIPE_SZ "
                        "failed: ", loop, p);
                perror("fcntl");
                exit(EXIT_FAILURE);
            }

            if (p == 0) {
                printf("        F_SETPIPE_SZ returned %d\n", s);
                rcap = s;
            } else {
                if (s != rcap) {
                    fprintf(stderr, "        Loop %d, pipe %d: F_SETPIPE_SZ "
                            "unexpected return: %d\n", loop, p, s);
                    exit(EXIT_FAILURE);
                }
            }

            stime = (j + 1 < argc) ? atoi(argv[j + 1]) : 0;
            if (stime > 0) {
                printf("        Sleeping %d seconds\n", stime);
                sleep(stime);
            }
        }
    }

    exit(EXIT_SUCCESS);
}

8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---

Patch history:

v2
   * Switch order of test in 'if' statement to avoid function call
      (to capability()) in normal path. [This is a fix to a preexisting
      wart in the code. Thanks to Willy Tarreau]
    * Perform (size > pipe_max_size) check before calling
      account_pipe_buffers().  [Thanks to Vegard Nossum]
      Quoting Vegard:

        The potential problem happens if the user passes a very large number
        which will overflow pipe->user->pipe_bufs.

        On 32-bit, sizeof(int) == sizeof(long), so if they pass arg = INT_MAX
        then round_pipe_size() returns INT_MAX. Although it's true that the
        accounting is done in terms of pages and not bytes, so you'd need on
        the order of (1 << 13) = 8192 processes hitting the limit at the same
        time in order to make it overflow, which seems a bit unlikely.

        (See https://lkml.org/lkml/2016/8/12/215 for another discussion on the
        limit checking)

Cc: Willy Tarreau <w@1wt.eu>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: socketpair@gmail.com
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Jens Axboe <axboe@fb.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-api@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
---
 fs/pipe.c | 41 +++++++++++++++++++++++++++++++----------
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/fs/pipe.c b/fs/pipe.c
index 37b7f5e..f45a173 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -1030,6 +1030,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 {
 	struct pipe_buffer *bufs;
 	unsigned int size, nr_pages;
+	long ret = 0;
 
 	size = round_pipe_size(arg);
 	nr_pages = size >> PAGE_SHIFT;
@@ -1037,13 +1038,26 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 	if (!nr_pages)
 		return -EINVAL;
 
-	if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size)
+	/*
+	 * If trying to increase the pipe capacity, check that an
+	 * unprivileged user is not trying to exceed various limits
+	 * (soft limit check here, hard limit check just below).
+	 * Decreasing the pipe capacity is always permitted, even
+	 * if the user is currently over a limit.
+	 */
+	if (nr_pages > pipe->buffers &&
+			size > pipe_max_size && !capable(CAP_SYS_RESOURCE))
 		return -EPERM;
 
-	if ((too_many_pipe_buffers_hard(pipe->user) ||
-			too_many_pipe_buffers_soft(pipe->user)) &&
-			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
-		return -EPERM;
+	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
+
+	if (nr_pages > pipe->buffers &&
+			(too_many_pipe_buffers_hard(pipe->user) ||
+			 too_many_pipe_buffers_soft(pipe->user)) &&
+			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
+		ret = -EPERM;
+		goto out_revert_acct;
+	}
 
 	/*
 	 * We can shrink the pipe, if arg >= pipe->nrbufs. Since we don't
@@ -1051,13 +1065,17 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 	 * again like we would do for growing. If the pipe currently
 	 * contains more buffers than arg, then return busy.
 	 */
-	if (nr_pages < pipe->nrbufs)
-		return -EBUSY;
+	if (nr_pages < pipe->nrbufs) {
+		ret = -EBUSY;
+		goto out_revert_acct;
+	}
 
 	bufs = kcalloc(nr_pages, sizeof(*bufs),
 		       GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
-	if (unlikely(!bufs))
-		return -ENOMEM;
+	if (unlikely(!bufs)) {
+		ret = -ENOMEM;
+		goto out_revert_acct;
+	}
 
 	/*
 	 * The pipe array wraps around, so just start the new one at zero
@@ -1080,12 +1098,15 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 			memcpy(bufs + head, pipe->bufs, tail * sizeof(struct pipe_buffer));
 	}
 
-	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
 	pipe->curbuf = 0;
 	kfree(pipe->bufs);
 	pipe->bufs = bufs;
 	pipe->buffers = nr_pages;
 	return nr_pages * PAGE_SIZE;
+
+out_revert_acct:
+	account_pipe_buffers(pipe->user, nr_pages, pipe->buffers);
+	return ret;
 }
 
 /*
-- 
2.5.5

^ permalink raw reply related	[relevance 51%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-21 21:35 99%       ` Willy Tarreau
@ 2016-08-22 19:37 99%         ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 13+ results
From: Michael Kerrisk (man-pages) @ 2016-08-22 19:37 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: mtk.manpages, Andrew Morton, Vegard Nossum, socketpair,
	Tetsuo Handa, Jens Axboe, Al Viro, linux-api, linux-kernel

Hi Willy,

On 08/22/2016 09:35 AM, Willy Tarreau wrote:
> Hi Michael,
> 
> On Mon, Aug 22, 2016 at 09:15:35AM +1200, Michael Kerrisk (man-pages) wrote:
>> Hi Willy,
>>
>> Might you have a chance to further review of this patch series?
>> It would be great if you could, since much of it touches changes
>> made by you earlier.
> 
> Well, all I did there was implementing a suggestion from Linus, but I'm
> not a specialist at all there. However I've read all your series and at
> least with my limited knowledge, all I've read seems to make sense at
> the code matches the descriptions. I don't remember any particular trap
> in this place so I'm not worried.

Okay.

> I remember that I noticed this inaccuracy in the accounting but I
> estimated it was not important since the goal was to *limit* resource
> usage with a simple patch that we could easily backport. Your approach
> looks clean and possibly backportable if needed. That's all I can say
> I'm afraid :-/

No problem. Thanks for the reply!

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-21 21:15 99%     ` Michael Kerrisk (man-pages)
@ 2016-08-21 21:35 99%       ` Willy Tarreau
  2016-08-22 19:37 99%         ` Michael Kerrisk (man-pages)
  0 siblings, 1 reply; 13+ results
From: Willy Tarreau @ 2016-08-21 21:35 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages)
  Cc: Andrew Morton, Vegard Nossum, socketpair, Tetsuo Handa,
	Jens Axboe, Al Viro, linux-api, linux-kernel

Hi Michael,

On Mon, Aug 22, 2016 at 09:15:35AM +1200, Michael Kerrisk (man-pages) wrote:
> Hi Willy,
> 
> Might you have a chance to further review of this patch series?
> It would be great if you could, since much of it touches changes
> made by you earlier.

Well, all I did there was implementing a suggestion from Linus, but I'm
not a specialist at all there. However I've read all your series and at
least with my limited knowledge, all I've read seems to make sense at
the code matches the descriptions. I don't remember any particular trap
in this place so I'm not worried.

I remember that I noticed this inaccuracy in the accounting but I
estimated it was not important since the goal was to *limit* resource
usage with a simple patch that we could easily backport. Your approach
looks clean and possibly backportable if needed. That's all I can say
I'm afraid :-/

Cheers,
Willy

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-19  5:48 99%   ` Willy Tarreau
  2016-08-19 20:51 99%     ` Michael Kerrisk (man-pages)
@ 2016-08-21 21:15 99%     ` Michael Kerrisk (man-pages)
  2016-08-21 21:35 99%       ` Willy Tarreau
  1 sibling, 1 reply; 13+ results
From: Michael Kerrisk (man-pages) @ 2016-08-21 21:15 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: mtk.manpages, Andrew Morton, Vegard Nossum, socketpair,
	Tetsuo Handa, Jens Axboe, Al Viro, linux-api, linux-kernel

Hi Willy,

Might you have a chance to further review of this patch series?
It would be great if you could, since much of it touches changes
made by you earlier.

Thanks,

Michael

On 08/19/2016 05:48 PM, Willy Tarreau wrote:
> Hi Michael,
> 
> Since you're changing this code, it's probably worth swapping the size
> check and capable() below to save a function call in the normal path :
> 
> On Fri, Aug 19, 2016 at 05:25:35PM +1200, Michael Kerrisk (man-pages) wrote:
>> +	if (nr_pages > pipe->buffers) {
>> +		if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) {
> 
> =>		if (size > pipe_max_size && !capable(CAP_SYS_RESOURCE)) {
> 
>> +			ret = -EPERM;
>> +			goto out_revert_acct;
>> +		} else if ((too_many_pipe_buffers_hard(pipe->user) ||
>> +				too_many_pipe_buffers_soft(pipe->user)) &&
>> +				!capable(CAP_SYS_RESOURCE) &&
>> +				!capable(CAP_SYS_ADMIN)) {
>> +			ret = -EPERM;
>> +			goto out_revert_acct;
>> +		}
>> +	}
> (...)
> 
> Cheers,
> Willy
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-21 10:33 99%         ` Vegard Nossum
@ 2016-08-21 21:14 99%           ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 13+ results
From: Michael Kerrisk (man-pages) @ 2016-08-21 21:14 UTC (permalink / raw)
  To: Vegard Nossum, Andrew Morton
  Cc: mtk.manpages, Willy Tarreau, socketpair, Tetsuo Handa,
	Jens Axboe, Al Viro, linux-api, linux-kernel

On 08/21/2016 10:33 PM, Vegard Nossum wrote:
> On 08/20/2016 01:17 AM, Michael Kerrisk (man-pages) wrote:
>> On 08/20/2016 08:56 AM, Michael Kerrisk (man-pages) wrote:
>>> On 08/19/2016 08:30 PM, Vegard Nossum wrote:
>>>> Is there any reason why we couldn't do the (size > pipe_max_size) check
>>>> before calling account_pipe_buffers()?
>>>
>>> No reason that I can see. Just a little more work to be done in the
>>> code, I think.
>>
>> And, just so I make sure we're understanding each other... I assume you
>> mean changing the code here to something like:
> [...]
>>         if (nr_pages > pipe->buffers &&
>>                         size > pipe_max_size && !capable(CAP_SYS_RESOURCE))
>>                 return -EPERM;
>>
>>         user_bufs = account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
>>
>>         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)) {
>>                 ret = -EPERM;
>>                 goto out_revert_acct;
>>         }
>>
>> Right?
> 
> Yup, that's what I had in mind.

Okay -- changed.

> (The parantheses are messed up though.)

Yup, was just a quick untested edit to make sure we meant the same thing.

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-19 23:17 98%       ` Michael Kerrisk (man-pages)
@ 2016-08-21 10:33 99%         ` Vegard Nossum
  2016-08-21 21:14 99%           ` Michael Kerrisk (man-pages)
  0 siblings, 1 reply; 13+ results
From: Vegard Nossum @ 2016-08-21 10:33 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages), Andrew Morton
  Cc: Willy Tarreau, socketpair, Tetsuo Handa, Jens Axboe, Al Viro,
	linux-api, linux-kernel

On 08/20/2016 01:17 AM, Michael Kerrisk (man-pages) wrote:
> On 08/20/2016 08:56 AM, Michael Kerrisk (man-pages) wrote:
>> On 08/19/2016 08:30 PM, Vegard Nossum wrote:
>>> Is there any reason why we couldn't do the (size > pipe_max_size) check
>>> before calling account_pipe_buffers()?
>>
>> No reason that I can see. Just a little more work to be done in the
>> code, I think.
>
> And, just so I make sure we're understanding each other... I assume you
> mean changing the code here to something like:
[...]
>         if (nr_pages > pipe->buffers &&
>                         size > pipe_max_size && !capable(CAP_SYS_RESOURCE))
>                 return -EPERM;
>
>         user_bufs = account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
>
>         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)) {
>                 ret = -EPERM;
>                 goto out_revert_acct;
>         }
>
> Right?

Yup, that's what I had in mind. (The parantheses are messed up though.)


Vegard

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-19 20:56 99%     ` Michael Kerrisk (man-pages)
@ 2016-08-19 23:17 98%       ` Michael Kerrisk (man-pages)
  2016-08-21 10:33 99%         ` Vegard Nossum
  0 siblings, 1 reply; 13+ results
From: Michael Kerrisk (man-pages) @ 2016-08-19 23:17 UTC (permalink / raw)
  To: Vegard Nossum, Andrew Morton
  Cc: mtk.manpages, Willy Tarreau, socketpair, Tetsuo Handa,
	Jens Axboe, Al Viro, linux-api, linux-kernel

On 08/20/2016 08:56 AM, Michael Kerrisk (man-pages) wrote:
> Hi Vegard,
> 
> On 08/19/2016 08:30 PM, Vegard Nossum wrote:
>> On 08/19/2016 07:25 AM, Michael Kerrisk (man-pages) wrote:
>>> The limit checking in pipe_set_size() (used by fcntl(F_SETPIPE_SZ))
>>> has the following problems:
>> [...]
>>> @@ -1030,6 +1030,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
>>>   {
>>>   	struct pipe_buffer *bufs;
>>>   	unsigned int size, nr_pages;
>>> +	long ret = 0;
>>>
>>>   	size = round_pipe_size(arg);
>>>   	nr_pages = size >> PAGE_SHIFT;
>>> @@ -1037,13 +1038,26 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
>>>   	if (!nr_pages)
>>>   		return -EINVAL;
>>>
>>> -	if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size)
>>> -		return -EPERM;
>>> +	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
>>>
>>> -	if ((too_many_pipe_buffers_hard(pipe->user) ||
>>> -			too_many_pipe_buffers_soft(pipe->user)) &&
>>> -			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
>>> -		return -EPERM;
>>> +	/*
>>> +	 * If trying to increase the pipe capacity, check that an
>>> +	 * unprivileged user is not trying to exceed various limits.
>>> +	 * (Decreasing the pipe capacity is always permitted, even
>>> +	 * if the user is currently over a limit.)
>>> +	 */
>>> +	if (nr_pages > pipe->buffers) {
>>> +		if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) {
>>> +			ret = -EPERM;
>>> +			goto out_revert_acct;
>>> +		} else if ((too_many_pipe_buffers_hard(pipe->user) ||
>>> +				too_many_pipe_buffers_soft(pipe->user)) &&
>>> +				!capable(CAP_SYS_RESOURCE) &&
>>> +				!capable(CAP_SYS_ADMIN)) {
>>> +			ret = -EPERM;
>>> +			goto out_revert_acct;
>>> +		}
>>> +	}
>>
>> I'm slightly worried about not checking arg/nr_pages before we pass it
>> on to account_pipe_buffers().
>>
>> The potential problem happens if the user passes a very large number
>> which will overflow pipe->user->pipe_bufs.
>>
>> On 32-bit, sizeof(int) == sizeof(long), so if they pass arg = INT_MAX
>> then round_pipe_size() returns INT_MAX. Although it's true that the
>> accounting is done in terms of pages and not bytes, so you'd need on the
>> order of (1 << 13) = 8192 processes hitting the limit at the same time
>> in order to make it overflow, which seems a bit unlikely.
>>
>> (See https://lkml.org/lkml/2016/8/12/215 for another discussion on the
>> limit checking)
>>
>> Is there any reason why we couldn't do the (size > pipe_max_size) check
>> before calling account_pipe_buffers()?
> 
> No reason that I can see. Just a little more work to be done in the
> code, I think.

And, just so I make sure we're understanding each other... I assume you
mean changing the code here to something like:

static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
{
        struct pipe_buffer *bufs;
        unsigned int size, nr_pages;
        unsigned long user_bufs;
        long ret = 0;

        size = round_pipe_size(arg);
        nr_pages = size >> PAGE_SHIFT;

        if (!nr_pages)
                return -EINVAL;

        /*
         * If trying to increase the pipe capacity, check that an
         * unprivileged user is not trying to exceed various limits
         * (soft limit check here, hard limit check just below).
         * Decreasing the pipe capacity is always permitted, even
         * if the user is currently over a limit.
         */
        if (nr_pages > pipe->buffers &&
                        size > pipe_max_size && !capable(CAP_SYS_RESOURCE))
                return -EPERM;

        user_bufs = account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);

        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)) {
                ret = -EPERM;
                goto out_revert_acct;
        }

Right?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[relevance 98%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-19  8:30 99%   ` Vegard Nossum
@ 2016-08-19 20:56 99%     ` Michael Kerrisk (man-pages)
  2016-08-19 23:17 98%       ` Michael Kerrisk (man-pages)
  0 siblings, 1 reply; 13+ results
From: Michael Kerrisk (man-pages) @ 2016-08-19 20:56 UTC (permalink / raw)
  To: Vegard Nossum, Andrew Morton
  Cc: mtk.manpages, Willy Tarreau, socketpair, Tetsuo Handa,
	Jens Axboe, Al Viro, linux-api, linux-kernel

Hi Vegard,

On 08/19/2016 08:30 PM, Vegard Nossum wrote:
> On 08/19/2016 07:25 AM, Michael Kerrisk (man-pages) wrote:
>> The limit checking in pipe_set_size() (used by fcntl(F_SETPIPE_SZ))
>> has the following problems:
> [...]
>> @@ -1030,6 +1030,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
>>   {
>>   	struct pipe_buffer *bufs;
>>   	unsigned int size, nr_pages;
>> +	long ret = 0;
>>
>>   	size = round_pipe_size(arg);
>>   	nr_pages = size >> PAGE_SHIFT;
>> @@ -1037,13 +1038,26 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
>>   	if (!nr_pages)
>>   		return -EINVAL;
>>
>> -	if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size)
>> -		return -EPERM;
>> +	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
>>
>> -	if ((too_many_pipe_buffers_hard(pipe->user) ||
>> -			too_many_pipe_buffers_soft(pipe->user)) &&
>> -			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
>> -		return -EPERM;
>> +	/*
>> +	 * If trying to increase the pipe capacity, check that an
>> +	 * unprivileged user is not trying to exceed various limits.
>> +	 * (Decreasing the pipe capacity is always permitted, even
>> +	 * if the user is currently over a limit.)
>> +	 */
>> +	if (nr_pages > pipe->buffers) {
>> +		if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) {
>> +			ret = -EPERM;
>> +			goto out_revert_acct;
>> +		} else if ((too_many_pipe_buffers_hard(pipe->user) ||
>> +				too_many_pipe_buffers_soft(pipe->user)) &&
>> +				!capable(CAP_SYS_RESOURCE) &&
>> +				!capable(CAP_SYS_ADMIN)) {
>> +			ret = -EPERM;
>> +			goto out_revert_acct;
>> +		}
>> +	}
> 
> I'm slightly worried about not checking arg/nr_pages before we pass it
> on to account_pipe_buffers().
> 
> The potential problem happens if the user passes a very large number
> which will overflow pipe->user->pipe_bufs.
> 
> On 32-bit, sizeof(int) == sizeof(long), so if they pass arg = INT_MAX
> then round_pipe_size() returns INT_MAX. Although it's true that the
> accounting is done in terms of pages and not bytes, so you'd need on the
> order of (1 << 13) = 8192 processes hitting the limit at the same time
> in order to make it overflow, which seems a bit unlikely.
> 
> (See https://lkml.org/lkml/2016/8/12/215 for another discussion on the
> limit checking)
> 
> Is there any reason why we couldn't do the (size > pipe_max_size) check
> before calling account_pipe_buffers()?

No reason that I can see. Just a little more work to be done in the
code, I think.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-19  5:48 99%   ` Willy Tarreau
@ 2016-08-19 20:51 99%     ` Michael Kerrisk (man-pages)
  2016-08-21 21:15 99%     ` Michael Kerrisk (man-pages)
  1 sibling, 0 replies; 13+ results
From: Michael Kerrisk (man-pages) @ 2016-08-19 20:51 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: mtk.manpages, Andrew Morton, Vegard Nossum, socketpair,
	Tetsuo Handa, Jens Axboe, Al Viro, linux-api, linux-kernel

On 08/19/2016 05:48 PM, Willy Tarreau wrote:
> Hi Michael,
> 
> Since you're changing this code, it's probably worth swapping the size
> check and capable() below to save a function call in the normal path :
> 
> On Fri, Aug 19, 2016 at 05:25:35PM +1200, Michael Kerrisk (man-pages) wrote:
>> +	if (nr_pages > pipe->buffers) {
>> +		if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) {
> 
> =>		if (size > pipe_max_size && !capable(CAP_SYS_RESOURCE)) {
> 
>> +			ret = -EPERM;
>> +			goto out_revert_acct;
>> +		} else if ((too_many_pipe_buffers_hard(pipe->user) ||
>> +				too_many_pipe_buffers_soft(pipe->user)) &&
>> +				!capable(CAP_SYS_RESOURCE) &&
>> +				!capable(CAP_SYS_ADMIN)) {
>> +			ret = -EPERM;
>> +			goto out_revert_acct;
>> +		}
>> +	}
> (...)

Thanks, Willy. Fixed for the next iteration. (And I made the same fix made 
also in the 8/8 patch).

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-19  5:25 53% ` [PATCH 4/8] pipe: fix limit checking in pipe_set_size() Michael Kerrisk (man-pages)
  2016-08-19  5:48 99%   ` Willy Tarreau
@ 2016-08-19  8:30 99%   ` Vegard Nossum
  2016-08-19 20:56 99%     ` Michael Kerrisk (man-pages)
  1 sibling, 1 reply; 13+ results
From: Vegard Nossum @ 2016-08-19  8:30 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages), Andrew Morton
  Cc: Willy Tarreau, socketpair, Tetsuo Handa, Jens Axboe, Al Viro,
	linux-api, linux-kernel

On 08/19/2016 07:25 AM, Michael Kerrisk (man-pages) wrote:
> The limit checking in pipe_set_size() (used by fcntl(F_SETPIPE_SZ))
> has the following problems:
[...]
> @@ -1030,6 +1030,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
>   {
>   	struct pipe_buffer *bufs;
>   	unsigned int size, nr_pages;
> +	long ret = 0;
>
>   	size = round_pipe_size(arg);
>   	nr_pages = size >> PAGE_SHIFT;
> @@ -1037,13 +1038,26 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
>   	if (!nr_pages)
>   		return -EINVAL;
>
> -	if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size)
> -		return -EPERM;
> +	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
>
> -	if ((too_many_pipe_buffers_hard(pipe->user) ||
> -			too_many_pipe_buffers_soft(pipe->user)) &&
> -			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> -		return -EPERM;
> +	/*
> +	 * If trying to increase the pipe capacity, check that an
> +	 * unprivileged user is not trying to exceed various limits.
> +	 * (Decreasing the pipe capacity is always permitted, even
> +	 * if the user is currently over a limit.)
> +	 */
> +	if (nr_pages > pipe->buffers) {
> +		if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) {
> +			ret = -EPERM;
> +			goto out_revert_acct;
> +		} else if ((too_many_pipe_buffers_hard(pipe->user) ||
> +				too_many_pipe_buffers_soft(pipe->user)) &&
> +				!capable(CAP_SYS_RESOURCE) &&
> +				!capable(CAP_SYS_ADMIN)) {
> +			ret = -EPERM;
> +			goto out_revert_acct;
> +		}
> +	}

I'm slightly worried about not checking arg/nr_pages before we pass it
on to account_pipe_buffers().

The potential problem happens if the user passes a very large number
which will overflow pipe->user->pipe_bufs.

On 32-bit, sizeof(int) == sizeof(long), so if they pass arg = INT_MAX
then round_pipe_size() returns INT_MAX. Although it's true that the
accounting is done in terms of pages and not bytes, so you'd need on the
order of (1 << 13) = 8192 processes hitting the limit at the same time
in order to make it overflow, which seems a bit unlikely.

(See https://lkml.org/lkml/2016/8/12/215 for another discussion on the
limit checking)

Is there any reason why we couldn't do the (size > pipe_max_size) check
before calling account_pipe_buffers()?


Vegard

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
  2016-08-19  5:25 53% ` [PATCH 4/8] pipe: fix limit checking in pipe_set_size() Michael Kerrisk (man-pages)
@ 2016-08-19  5:48 99%   ` Willy Tarreau
  2016-08-19 20:51 99%     ` Michael Kerrisk (man-pages)
  2016-08-21 21:15 99%     ` Michael Kerrisk (man-pages)
  2016-08-19  8:30 99%   ` Vegard Nossum
  1 sibling, 2 replies; 13+ results
From: Willy Tarreau @ 2016-08-19  5:48 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages)
  Cc: Andrew Morton, Vegard Nossum, socketpair, Tetsuo Handa,
	Jens Axboe, Al Viro, linux-api, linux-kernel

Hi Michael,

Since you're changing this code, it's probably worth swapping the size
check and capable() below to save a function call in the normal path :

On Fri, Aug 19, 2016 at 05:25:35PM +1200, Michael Kerrisk (man-pages) wrote:
> +	if (nr_pages > pipe->buffers) {
> +		if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) {

=>		if (size > pipe_max_size && !capable(CAP_SYS_RESOURCE)) {

> +			ret = -EPERM;
> +			goto out_revert_acct;
> +		} else if ((too_many_pipe_buffers_hard(pipe->user) ||
> +				too_many_pipe_buffers_soft(pipe->user)) &&
> +				!capable(CAP_SYS_RESOURCE) &&
> +				!capable(CAP_SYS_ADMIN)) {
> +			ret = -EPERM;
> +			goto out_revert_acct;
> +		}
> +	}
(...)

Cheers,
Willy

^ permalink raw reply	[relevance 99%]

* [PATCH 4/8] pipe: fix limit checking in pipe_set_size()
       [not found]     <67ce15aa-cf43-0c89-d079-2d966177c56d@gmail.com>
@ 2016-08-19  5:25 53% ` Michael Kerrisk (man-pages)
  2016-08-19  5:48 99%   ` Willy Tarreau
  2016-08-19  8:30 99%   ` Vegard Nossum
  0 siblings, 2 replies; 13+ results
From: Michael Kerrisk (man-pages) @ 2016-08-19  5:25 UTC (permalink / raw)
  To: Andrew Morton
  Cc: mtk.manpages, Willy Tarreau, Vegard Nossum, socketpair,
	Tetsuo Handa, Jens Axboe, Al Viro, linux-api, linux-kernel

The limit checking in pipe_set_size() (used by fcntl(F_SETPIPE_SZ))
has the following problems:

(1) When increasing the pipe capacity, the checks against the limits
    in /proc/sys/fs/pipe-user-pages-{soft,hard} are made against
    existing consumption, and exclude the memory required for the
    increased pipe capacity. The new increase in pipe capacity
    can then push the total memory used by the user for pipes
    (possibly far) over a limit. This can also trigger the problem
    described next.

(2) The limit checks are performed even when the new pipe capacity
    is less than the existing pipe capacity. This can lead to
    problems if a user sets a large pipe capacity, and then the
    limits are lowered, with the result that the user will no
    longer be able to decrease the pipe capacity.

(3) As currently implemented, accounting and checking against the limits
    is done as follows:

    (a) Test whether the user has exceeded the limit.
    (b) Make new pipe buffer allocation.
    (c) Account new allocation against the limits.

    This is racey. Multiple processes may pass point (a) simultaneously,
    and then allocate pipe buffers that are accounted for only in step (c).
    The race means that the user's pipe buffer allocation could be pushed
    over the limit (by an arbitrary amount, depending on how unlucky we
    were in the race). [Thanks to Vegard Nossum for spotting this point,
    which I had missed.]

This patch addresses the above problems as follows:

* Perform checks against the limits only when increasing a pipe's
  capacity; an unprivileged user can always decrease a pipe's capacity.
* Alter the checks against limits to include the memory required for the
  new pipe capacity.
* Re-order the accounting step so that it precedes the buffer
  allocation. If the accounting step determines that a limit has
  been reached, revert the accounting and cause the operation to fail.

The program below can be used to demonstrate problems 1 and 2, and the
effect of the fix. The program takes one or more command-line
arguments. The first argument specifies the number of pipes that the
program should create. The remaining arguments are, alternately, pipe
capacities that should be set using fcntl(F_SETPIPE_SZ), and sleep
intervals (in seconds) between the fcntl() operations. (The sleep
intervals allow the possibility to change the limits between fcntl()
operations.)

Problem 1
=========

Using the test program on an unpatched kernel, we first set some limits:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard    # 40.96 MB

Then show that we can set a pipe with capacity (100MB) that is
over the hard limit

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            F_SETPIPE_SZ returned 134217728

Now set the capacity to 100MB twice. The second call fails (which is
probably surprising to most users, since it seems like a no-op):

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000 0 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            F_SETPIPE_SZ returned 134217728
        Loop 2: set pipe capacity to 100000000 bytes
            Loop 2, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

With a patched kernel, setting a capacity over the limit fails at the
first attempt:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard
    # sudo -u mtk ./test_F_SETPIPE_SZ 1 100000000
    Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 100000000 bytes
            Loop 1, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

There is a small chance that the change to fix this problem could
break user-space, since there are cases where fcntl(F_SETPIPE_SZ)
calls that previously succeeded might fail. However, the chances
are small, since (a) the pipe-user-pages-{soft,hard} limits are
new (in 4.5), and the default soft/hard limits are high/unlimited.
Therefore, it seems warranted to make these limits operate more
precisely (and behave more like what users probably expect).

Problem 2
=========

Running the test program on an unpatched kernel, we first set some limits:

    # getconf PAGESIZE
    4096
    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard    # 40.96 MB

Now perform two fcntl(F_SETPIPE_SZ) operations on a single pipe,
first setting a pipe capacity (10MB), sleeping for a few seconds,
during which time the hard limit is lowered, and then set pipe
capacity to a smaller amount (5MB):

    # sudo -u mtk ./test_F_SETPIPE_SZ 1 10000000 15 5000000 &
    [1] 748
    # Initial pipe capacity: 65536
        Loop 1: set pipe capacity to 10000000 bytes
            F_SETPIPE_SZ returned 16777216
            Sleeping 15 seconds

    # echo 1000 > /proc/sys/fs/pipe-user-pages-hard      # 4.096 MB
    #     Loop 2: set pipe capacity to 5000000 bytes
            Loop 2, pipe 0: F_SETPIPE_SZ failed: fcntl: Operation not permitted

In this case, the user should be able to lower the limit.

With a kernel that has the patch below, the second fcntl()
succeeds:

    # echo 0 > /proc/sys/fs/pipe-user-pages-soft
    # echo 1000000000 > /proc/sys/fs/pipe-max-size
    # echo 10000 > /proc/sys/fs/pipe-user-pages-hard
    # sudo -u mtk ./test_F_SETPIPE_SZ 1 10000000 15 5000000 &
    [1] 3215
    # Initial pipe capacity: 65536
    #     Loop 1: set pipe capacity to 10000000 bytes
            F_SETPIPE_SZ returned 16777216
            Sleeping 15 seconds

    # echo 1000 > /proc/sys/fs/pipe-user-pages-hard

    #     Loop 2: set pipe capacity to 5000000 bytes
            F_SETPIPE_SZ returned 8388608

8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---

/* test_F_SETPIPE_SZ.c 

   (C) 2016, Michael Kerrisk; licensed under GNU GPL version 2 or later

   Test operation of fcntl(F_SETPIPE_SZ) for setting pipe capacity
   and interactions with limits defined by /proc/sys/fs/pipe-* files.
*/

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
    int (*pfd)[2];
    int npipes;
    int pcap, rcap;
    int j, p, s, stime, loop;

    if (argc < 2) {
        fprintf(stderr, "Usage: %s num-pipes "
                "[pipe-capacity sleep-time]...\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    npipes = atoi(argv[1]);

    pfd = calloc(npipes, sizeof (int [2]));
    if (pfd == NULL) {
        perror("calloc");
        exit(EXIT_FAILURE);
    }

    for (j = 0; j < npipes; j++) {
        if (pipe(pfd[j]) == -1) {
            fprintf(stderr, "Loop %d: pipe() failed: ", j);
            perror("pipe");
            exit(EXIT_FAILURE);
        }
    }

    printf("Initial pipe capacity: %d\n", fcntl(pfd[0][0], F_GETPIPE_SZ));

    for (j = 2; j < argc; j += 2 ) {
        loop = j / 2;
        pcap = atoi(argv[j]);
        printf("    Loop %d: set pipe capacity to %d bytes\n", loop, pcap);

        for (p = 0; p < npipes; p++) {
            s = fcntl(pfd[p][0], F_SETPIPE_SZ, pcap);
            if (s == -1) {
                fprintf(stderr, "        Loop %d, pipe %d: F_SETPIPE_SZ "
                        "failed: ", loop, p);
                perror("fcntl");
                exit(EXIT_FAILURE);
            }

            if (p == 0) {
                printf("        F_SETPIPE_SZ returned %d\n", s);
                rcap = s;
            } else {
                if (s != rcap) {
                    fprintf(stderr, "        Loop %d, pipe %d: F_SETPIPE_SZ "
                            "unexpected return: %d\n", loop, p, s);
                    exit(EXIT_FAILURE);
                }
            }

            stime = (j + 1 < argc) ? atoi(argv[j + 1]) : 0;
            if (stime > 0) {
                printf("        Sleeping %d seconds\n", stime);
                sleep(stime);
            }
        }
    }

    exit(EXIT_SUCCESS);
}
8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---8x---


Cc: Willy Tarreau <w@1wt.eu>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: socketpair@gmail.com
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Jens Axboe <axboe@fb.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-api@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

---
 fs/pipe.c | 43 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/fs/pipe.c b/fs/pipe.c
index 37b7f5e..a7470a9 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -1030,6 +1030,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 {
 	struct pipe_buffer *bufs;
 	unsigned int size, nr_pages;
+	long ret = 0;
 
 	size = round_pipe_size(arg);
 	nr_pages = size >> PAGE_SHIFT;
@@ -1037,13 +1038,26 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 	if (!nr_pages)
 		return -EINVAL;
 
-	if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size)
-		return -EPERM;
+	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
 
-	if ((too_many_pipe_buffers_hard(pipe->user) ||
-			too_many_pipe_buffers_soft(pipe->user)) &&
-			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
-		return -EPERM;
+	/*
+	 * If trying to increase the pipe capacity, check that an
+	 * unprivileged user is not trying to exceed various limits.
+	 * (Decreasing the pipe capacity is always permitted, even
+	 * if the user is currently over a limit.)
+	 */
+	if (nr_pages > pipe->buffers) {
+		if (!capable(CAP_SYS_RESOURCE) && size > pipe_max_size) {
+			ret = -EPERM;
+			goto out_revert_acct;
+		} else if ((too_many_pipe_buffers_hard(pipe->user) ||
+				too_many_pipe_buffers_soft(pipe->user)) &&
+				!capable(CAP_SYS_RESOURCE) &&
+				!capable(CAP_SYS_ADMIN)) {
+			ret = -EPERM;
+			goto out_revert_acct;
+		}
+	}
 
 	/*
 	 * We can shrink the pipe, if arg >= pipe->nrbufs. Since we don't
@@ -1051,13 +1065,17 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 	 * again like we would do for growing. If the pipe currently
 	 * contains more buffers than arg, then return busy.
 	 */
-	if (nr_pages < pipe->nrbufs)
-		return -EBUSY;
+	if (nr_pages < pipe->nrbufs) {
+		ret = -EBUSY;
+		goto out_revert_acct;
+	}
 
 	bufs = kcalloc(nr_pages, sizeof(*bufs),
 		       GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
-	if (unlikely(!bufs))
-		return -ENOMEM;
+	if (unlikely(!bufs)) {
+		ret = -ENOMEM;
+		goto out_revert_acct;
+	}
 
 	/*
 	 * The pipe array wraps around, so just start the new one at zero
@@ -1080,12 +1098,15 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
 			memcpy(bufs + head, pipe->bufs, tail * sizeof(struct pipe_buffer));
 	}
 
-	account_pipe_buffers(pipe->user, pipe->buffers, nr_pages);
 	pipe->curbuf = 0;
 	kfree(pipe->bufs);
 	pipe->bufs = bufs;
 	pipe->buffers = nr_pages;
 	return nr_pages * PAGE_SIZE;
+
+out_revert_acct:
+	account_pipe_buffers(pipe->user, nr_pages, pipe->buffers);
+	return ret;
 }
 
 /*
-- 
2.5.5

^ permalink raw reply related	[relevance 53%]

Results 1-13 of 13 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
     [not found]     <67ce15aa-cf43-0c89-d079-2d966177c56d@gmail.com>
2016-08-19  5:25 53% ` [PATCH 4/8] pipe: fix limit checking in pipe_set_size() Michael Kerrisk (man-pages)
2016-08-19  5:48 99%   ` Willy Tarreau
2016-08-19 20:51 99%     ` Michael Kerrisk (man-pages)
2016-08-21 21:15 99%     ` Michael Kerrisk (man-pages)
2016-08-21 21:35 99%       ` Willy Tarreau
2016-08-22 19:37 99%         ` Michael Kerrisk (man-pages)
2016-08-19  8:30 99%   ` Vegard Nossum
2016-08-19 20:56 99%     ` Michael Kerrisk (man-pages)
2016-08-19 23:17 98%       ` Michael Kerrisk (man-pages)
2016-08-21 10:33 99%         ` Vegard Nossum
2016-08-21 21:14 99%           ` Michael Kerrisk (man-pages)
     [not found]     <ef9ce203-6683-31b1-26dc-e0b823aba73e@gmail.com>
2016-08-29  0:21 51% ` [PATCH v2 " Michael Kerrisk (man-pages)
2018-06-07 14:05     [PATCH 3.16 000/410] 3.16.57-rc1 review Ben Hutchings
2018-06-07 14:05 50% ` [PATCH 3.16 202/410] pipe: fix limit checking in pipe_set_size() Ben Hutchings

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).