linux-kernel - [PATCH] perf/core: fix potential double-fetch bug

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>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1503522470-35531-1-git-send-email-meng.xu@gatech.edu>
Date:   Wed, 23 Aug 2017 17:07:50 -0400
From:   Meng Xu <meng.xu@...ech.edu>
To:     peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org
Cc:     meng.xu@...ech.edu, sanidhya@...ech.edu, taesoo@...ech.edu,
        Meng Xu <mengxu.gatech@...il.com>
Subject: [PATCH] perf/core: fix potential double-fetch bug

From: Meng Xu <mengxu.gatech@...il.com>

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.

Proposed patch:

The patch is a one-liner which overrides `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 in consistent with the checks
performed after the first fetch.

Signed-off-by: Meng Xu <mengxu.gatech@...il.com>
---
 kernel/events/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index ee20d4c..c0d7946 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;

-- 
2.7.4