linux-kernel - [PATCH 6/8] pipe: fix limit checking in alloc_pipe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 19 Aug 2016 17:25:48 +1200
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     mtk.manpages@...il.com, Willy Tarreau <w@....eu>,
        Vegard Nossum <vegard.nossum@...cle.com>, socketpair@...il.com,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Jens Axboe <axboe@...com>, Al Viro <viro@...iv.linux.org.uk>,
        linux-api@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 6/8] pipe: fix limit checking in alloc_pipe_info()

The limit checking in alloc_pipe_info() (used by pipe(2) and when
opening a FIFO) has the following problems:

(1) When checking capacity required for the new pipe, the checks
    against the limit in /proc/sys/fs/pipe-user-pages-{soft,hard}
    are made against existing consumption, and exclude the memory
    required for the new pipe capacity. As a consequence: (1) the
    memory allocation throttling provided by the soft limit does
    not kick in quite as early as it should, and (2) the user can
    overrun the hard limit.

(2) 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:

* Alter the checks against limits to include the memory required for the
  new pipe.
* 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.

Cc: Willy Tarreau <w@....eu>
Cc: Vegard Nossum <vegard.nossum@...cle.com>
Cc: socketpair@...il.com
Cc: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc: Jens Axboe <axboe@...com>
Cc: Al Viro <viro@...iv.linux.org.uk>
Cc: linux-api@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Signed-off-by: Michael Kerrisk <mtk.manpages@...il.com>

---
 fs/pipe.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/fs/pipe.c b/fs/pipe.c
index 613c6b9..705d79f 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -632,24 +632,28 @@ struct pipe_inode_info *alloc_pipe_info(void)
 	if (pipe == NULL)
 		goto out_free_uid;
 
-	if (!too_many_pipe_buffers_hard(user)) {
-		if (too_many_pipe_buffers_soft(user))
-			pipe_bufs = 1;
-		pipe->bufs = kcalloc(pipe_bufs,
-				     sizeof(struct pipe_buffer),
-				     GFP_KERNEL_ACCOUNT);
-	}
+	if (too_many_pipe_buffers_soft(user))
+		pipe_bufs = 1;
+
+	account_pipe_buffers(user, 0, pipe_bufs);
+
+	if (too_many_pipe_buffers_hard(user))
+		goto out_revert_acct;
+
+	pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
+			     GFP_KERNEL_ACCOUNT);
 
 	if (pipe->bufs) {
 		init_waitqueue_head(&pipe->wait);
 		pipe->r_counter = pipe->w_counter = 1;
 		pipe->buffers = pipe_bufs;
 		pipe->user = user;
-		account_pipe_buffers(user, 0, pipe_bufs);
 		mutex_init(&pipe->mutex);
 		return pipe;
 	}
 
+out_revert_acct:
+	account_pipe_buffers(user, pipe_bufs, 0);
 	kfree(pipe);
 out_free_uid:
 	free_uid(user);
-- 
2.5.5