Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2295270imm; Thu, 7 Jun 2018 08:20:23 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJex1i8K7jSq/MWfoU/3CsgrtSO3fs9jDO0UMZpzDnk+GvTJuKQYgzYoMT68XNOJ2GpdyGw X-Received: by 2002:a17:902:6e01:: with SMTP id u1-v6mr2491587plk.96.1528384822982; Thu, 07 Jun 2018 08:20:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528384822; cv=none; d=google.com; s=arc-20160816; b=LkVSRJXn3Kj9/BUcoyad5KCoz9VLALfJh5hVAKN6UseyfPhFNCBeGT+cUb+GF+TLK3 knhvhDmWBIHZgccJKHTgV/f/vQbPJDeUBu7mCwj4Cdib4PunHFW/LryscibvTLNr/tVa 7N9LV+WHeh0pyOsOyRjD+f9pQjZw7fiF9cRN2abrjZZv7RszZ2xD2jaYMpmdAuxpArzP YI0uA/vZJxoLrlOi5nY+JWHuq3BqFMU071LRqDvB8lHhuaETvXU3T2RUJRbTmNcsXxy7 5G5DXfXj2vVSj+VHtmncZH4O4P6863pRPcw3qTW9LStA/tIhxKByuIK9RBG7fqV6F4Sp RIow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=z2IURBCb9AN8uKo3ZD+fNYgQB/bt+Kz5PgGAgsZVlio=; b=q1cPwQu/H2oqy+ZuNuk446trGvYn1qV3fR/nun/pBqbiMGMefE4GGY71DE6rsvr4Ol 7oQMw5Y3W6J9j7B04mo6XLyZDf+pJOUZFuoI30LZBFaVRaJ53mnpzcobTaFnR4F6rJYb y+NOtMYSb8yJimE7Izb+lQHuuvkI6NfUBP2pKkl/96/nI2A8Am0NoYR7kKQnPpc4wHTu 388Z41sAB54e/Xlq5cm1YtbPc0g9EgcgRRQEsJ5is8Ogu6G5nuWeRmCgdUZ1jLMRie96 UIzjBPuULE3dM8Z+/KtJfB7EOAHUHWabD+3UKzBiLUZPL56UrUng46dN54yjEDWj9SRJ fRkQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v1-v6si1843916ply.458.2018.06.07.08.20.08; Thu, 07 Jun 2018 08:20:22 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935478AbeFGPSL (ORCPT + 99 others); Thu, 7 Jun 2018 11:18:11 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41298 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935720AbeFGO7l (ORCPT ); Thu, 7 Jun 2018 10:59:41 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbe-0005hJ-EC; Thu, 07 Jun 2018 15:09:38 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvb6-00031u-MQ; Thu, 07 Jun 2018 15:09:04 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Michael Kerrisk" , "Kees Cook" , "Mikulas Patocka" , "Eric Biggers" , "Alexander Viro" , "Willy Tarreau" , "Joe Lawrence" , "Linus Torvalds" , "Luis R . Rodriguez" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 216/410] pipe: read buffer limits atomically In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Eric Biggers commit f7340761812fc10313e6fcc115e0bc4f7a799112 upstream. 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. Link: http://lkml.kernel.org/r/20180111052902.14409-8-ebiggers3@gmail.com Signed-off-by: Eric Biggers Acked-by: Kees Cook Acked-by: Joe Lawrence Cc: Alexander Viro Cc: Michael Kerrisk Cc: Willy Tarreau Cc: Mikulas Patocka Cc: "Luis R . Rodriguez" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: - Use ACCESS_ONCE() instead of READ_ONCE() - Adjust context] Signed-off-by: Ben Hutchings --- fs/pipe.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/fs/pipe.c +++ b/fs/pipe.c @@ -593,12 +593,16 @@ static unsigned long account_pipe_buffer 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 = ACCESS_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 = ACCESS_ONCE(pipe_user_pages_hard); + + return hard_limit && user_bufs > hard_limit; } static bool is_unprivileged_user(void) @@ -612,13 +616,14 @@ struct pipe_inode_info *alloc_pipe_info( unsigned long pipe_bufs = PIPE_DEF_BUFFERS; struct user_struct *user = get_current_user(); unsigned long user_bufs; + unsigned int max_size = ACCESS_ONCE(pipe_max_size); pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL); 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);