From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752943AbdH2NKy (ORCPT ); Tue, 29 Aug 2017 09:10:54 -0400 Received: from terminus.zytor.com ([65.50.211.136]:56409 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752002AbdH2NKw (ORCPT ); Tue, 29 Aug 2017 09:10:52 -0400 Date: Tue, 29 Aug 2017 06:06:09 -0700 From: tip-bot for Meng Xu Message-ID: Cc: mingo@kernel.org, mengxu.gatech@gmail.com, torvalds@linux-foundation.org, tglx@linutronix.de, hpa@zytor.com, peterz@infradead.org, linux-kernel@vger.kernel.org Reply-To: mengxu.gatech@gmail.com, tglx@linutronix.de, torvalds@linux-foundation.org, hpa@zytor.com, peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <1503522470-35531-1-git-send-email-meng.xu@gatech.edu> References: <1503522470-35531-1-git-send-email-meng.xu@gatech.edu> To: linux-tip-commits@vger.kernel.org Subject: [tip:perf/urgent] perf/core: Fix potential double-fetch bug Git-Commit-ID: f12f42acdbb577a12eecfcebbbec41c81505c4dc X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: f12f42acdbb577a12eecfcebbbec41c81505c4dc Gitweb: http://git.kernel.org/tip/f12f42acdbb577a12eecfcebbbec41c81505c4dc Author: Meng Xu AuthorDate: Wed, 23 Aug 2017 17:07:50 -0400 Committer: Ingo Molnar CommitDate: Tue, 29 Aug 2017 13:26:22 +0200 perf/core: Fix potential double-fetch bug While examining the kernel source code, I found a dangerous operation that could turn into a double-fetch situation (a race condition bug) where the same userspace memory region are fetched twice into kernel with sanity checks after the first fetch while missing checks after the second fetch. 1. The first fetch happens in line 9573 get_user(size, &uattr->size). 2. Subsequently the 'size' variable undergoes a few sanity checks and transformations (line 9577 to 9584). 3. The second fetch happens in line 9610 copy_from_user(attr, uattr, size) 4. Given that 'uattr' can be fully controlled in userspace, an attacker can race condition to override 'uattr->size' to arbitrary value (say, 0xFFFFFFFF) after the first fetch but before the second fetch. The changed value will be copied to 'attr->size'. 5. There is no further checks on 'attr->size' until the end of this function, and once the function returns, we lose the context to verify that 'attr->size' conforms to the sanity checks performed in step 2 (line 9577 to 9584). 6. My manual analysis shows that 'attr->size' is not used elsewhere later, so, there is no working exploit against it right now. However, this could easily turns to an exploitable one if careless developers start to use 'attr->size' later. To fix this, override 'attr->size' from the second fetch to the one from the first fetch, regardless of what is actually copied in. In this way, it is assured that 'attr->size' is consistent with the checks performed after the first fetch. Signed-off-by: Meng Xu Acked-by: Peter Zijlstra Cc: Linus Torvalds Cc: Thomas Gleixner Cc: acme@kernel.org Cc: alexander.shishkin@linux.intel.com Cc: meng.xu@gatech.edu Cc: sanidhya@gatech.edu Cc: taesoo@gatech.edu Link: http://lkml.kernel.org/r/1503522470-35531-1-git-send-email-meng.xu@gatech.edu Signed-off-by: Ingo Molnar --- kernel/events/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index 3504125..ce131d2 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9611,6 +9611,8 @@ static int perf_copy_attr(struct perf_event_attr __user *uattr, if (ret) return -EFAULT; + attr->size = size; + if (attr->__reserved_1) return -EINVAL;