From patchwork Mon Jan 8 05:35:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 10149047 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 82274601BE for ; Mon, 8 Jan 2018 05:39:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 76B14287A6 for ; Mon, 8 Jan 2018 05:39:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6B66C287A8; Mon, 8 Jan 2018 05:39:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 24EC8287C5 for ; Mon, 8 Jan 2018 05:39:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755435AbeAHFj3 (ORCPT ); Mon, 8 Jan 2018 00:39:29 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:41403 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755534AbeAHFi5 (ORCPT ); Mon, 8 Jan 2018 00:38:57 -0500 Received: by mail-pg0-f66.google.com with SMTP id m17so2527197pgd.8; Sun, 07 Jan 2018 21:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=d3w/GEyFRJjZIEluBifUYsvlXU4Z0NCK0Ser2XV3Uww=; b=AeWTuv5RX0xzCUDKC8RNNmiita1nm16c/UfBTXdS9Yk6Fci8ORv1YTHvM7TxH0CgVj l4CqfyR9VUEljzHDQPNMhypmavt8GwFEgH3GKea7F8RC9lf2nRKP1mkFHrP7X1hEm262 9TKa2/Z0q+aKcMDvIkn4eHpnqkE8LdgDYG1jYVYQfEgR78cWBp3Q+JneSB6MIWKwBtlK rSNqgy3SJO1mOTRrRMiiUQH3irxOVg1mfiknYeVwA8SSAnElREBfqCokv9her6j2Yujy 964mm7M660bVk6TrvnAgdhlQgeVSz7RS3owrGBPM+wCjo2cRazx8mxCStkK6lPqSDjDs ja/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=d3w/GEyFRJjZIEluBifUYsvlXU4Z0NCK0Ser2XV3Uww=; b=A79kRQy9QuAeiz2wCPHDveGN9mMLMWqG4apOpZbIV7Phah3yxpMonhy4moeWDry5HX 1OfbQYEGpu3CLkX31iW31LWk0XKbeasBCXALyqUQyf7BZBwDgmvKv6PaYvArmsPlxyFc 1W7FVSpqYDBcxgqMewWzp8TYPHEYkNIilChFx12kUjhC2cPua2kbOB/gV5CK5/z+sHbb WSOpg9sNfCNocRHpRtYMgtXlHv8XOEfK6Q3s0Egb+Q1M+elVo3kKjXU7MWx1wyfgXrha HRPJEeouqV64l2pKOi+LGkuEzEoxKtRRr0yor3NB/0XfUn/4kQT2yyOLnL++08kZYYOU yb6A== X-Gm-Message-State: AKGB3mIaGgzre1GgWnmWMVyE5f2zb0Yt8NF9qaSsfSWdNU0Fmd4t+5mf 5EHzpK9iM+UZ6dPP7bUxqMDttiOG X-Google-Smtp-Source: ACJfBou+rWVGTz9Vffj7tOcwHTu9L7SuPdD0m9fJQ10SHv0RRVelJzHDR1qNIJeEg1mv8zVOvMozfw== X-Received: by 10.99.121.199 with SMTP id u190mr8046886pgc.314.1515389936513; Sun, 07 Jan 2018 21:38:56 -0800 (PST) Received: from zzz.localdomain (c-67-185-97-198.hsd1.wa.comcast.net. [67.185.97.198]) by smtp.gmail.com with ESMTPSA id w84sm26611743pfk.16.2018.01.07.21.38.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jan 2018 21:38:55 -0800 (PST) From: Eric Biggers To: linux-fsdevel@vger.kernel.org Cc: Alexander Viro , Joe Lawrence , Michael Kerrisk , Willy Tarreau , Mikulas Patocka , "Luis R . Rodriguez" , Kees Cook , linux-kernel@vger.kernel.org, Eric Biggers Subject: [PATCH 7/7] pipe: read buffer limits atomically Date: Sun, 7 Jan 2018 21:35:42 -0800 Message-Id: <20180108053542.6472-8-ebiggers3@gmail.com> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20180108053542.6472-1-ebiggers3@gmail.com> References: <20180108053542.6472-1-ebiggers3@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers The pipe buffer limits are accessed without any locking, and may be changed at any time by the sysctl handlers. In theory this could cause problems for expressions like the following: pipe_user_pages_hard && user_bufs > pipe_user_pages_hard ... since the assembly code might reference the 'pipe_user_pages_hard' memory location multiple times, and if the admin removes the limit by setting it to 0, there is a very brief window where processes could incorrectly observe the limit to be exceeded. Fix this by loading the limits with READ_ONCE() prior to use. Signed-off-by: Eric Biggers Acked-by: Kees Cook --- fs/pipe.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/fs/pipe.c b/fs/pipe.c index 774cafd947dc..2e2349602815 100644 --- a/fs/pipe.c +++ b/fs/pipe.c @@ -605,12 +605,16 @@ static unsigned long account_pipe_buffers(struct user_struct *user, static bool too_many_pipe_buffers_soft(unsigned long user_bufs) { - return pipe_user_pages_soft && user_bufs > pipe_user_pages_soft; + unsigned long soft_limit = READ_ONCE(pipe_user_pages_soft); + + return soft_limit && user_bufs > soft_limit; } static bool too_many_pipe_buffers_hard(unsigned long user_bufs) { - return pipe_user_pages_hard && user_bufs > pipe_user_pages_hard; + unsigned long hard_limit = READ_ONCE(pipe_user_pages_hard); + + return hard_limit && user_bufs > hard_limit; } static bool is_unprivileged_user(void) @@ -624,13 +628,14 @@ struct pipe_inode_info *alloc_pipe_info(void) unsigned long pipe_bufs = PIPE_DEF_BUFFERS; struct user_struct *user = get_current_user(); unsigned long user_bufs; + unsigned int max_size = READ_ONCE(pipe_max_size); pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL_ACCOUNT); if (pipe == NULL) goto out_free_uid; - if (pipe_bufs * PAGE_SIZE > pipe_max_size && !capable(CAP_SYS_RESOURCE)) - pipe_bufs = pipe_max_size >> PAGE_SHIFT; + if (pipe_bufs * PAGE_SIZE > max_size && !capable(CAP_SYS_RESOURCE)) + pipe_bufs = max_size >> PAGE_SHIFT; user_bufs = account_pipe_buffers(user, 0, pipe_bufs);