Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 16 Feb 2017 05:46:08 +0100
From: Salvatore Bonaccorso <carnil@...ian.org>
To: OSS Security Mailinglist <oss-security@...ts.openwall.com>
Cc: Ben Hutchings <benh@...ian.org>
Subject: Linux: CVE-2017-6001: Incomplete fix for CVE-2016-6786: perf/core:
 Fix concurrent sys_perf_event_open() vs. 'move_group' race

Hi

The original fix for CVE-2016-6786 ws incomplete. Upstream has
commited

https://git.kernel.org/linus/321027c1fe77f892f4ea07846aeae08cefbbb290

which is in v4.10-rc4 (and also backported to 4.9.x in v4.9.7). This
has been assigned a new CVE identifier: CVE-2017-6001 (assigned via ->
https://cveform.mitre.org/).

Commit message reads as:

> commit 321027c1fe77f892f4ea07846aeae08cefbbb290
> Author: Peter Zijlstra <peterz@...radead.org>
> Date:   Wed Jan 11 21:09:50 2017 +0100
> 
>     perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
>     
>     Di Shen reported a race between two concurrent sys_perf_event_open()
>     calls where both try and move the same pre-existing software group
>     into a hardware context.
>     
>     The problem is exactly that described in commit:
>     
>       f63a8daa5812 ("perf: Fix event->ctx locking")
>     
>     ... where, while we wait for a ctx->mutex acquisition, the event->ctx
>     relation can have changed under us.
>     
>     That very same commit failed to recognise sys_perf_event_context() as an
>     external access vector to the events and thereby didn't apply the
>     established locking rules correctly.
>     
>     So while one sys_perf_event_open() call is stuck waiting on
>     mutex_lock_double(), the other (which owns said locks) moves the group
>     about. So by the time the former sys_perf_event_open() acquires the
>     locks, the context we've acquired is stale (and possibly dead).
>     
>     Apply the established locking rules as per perf_event_ctx_lock_nested()
>     to the mutex_lock_double() for the 'move_group' case. This obviously means
>     we need to validate state after we acquire the locks.
>     
>     Reported-by: Di Shen (Keen Lab)
>     Tested-by: John Dias <joaodias@...gle.com>
>     Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>     Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
>     Cc: Arnaldo Carvalho de Melo <acme@...nel.org>
>     Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
>     Cc: Jiri Olsa <jolsa@...hat.com>
>     Cc: Kees Cook <keescook@...omium.org>
>     Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>     Cc: Min Chong <mchong@...gle.com>
>     Cc: Peter Zijlstra <peterz@...radead.org>
>     Cc: Stephane Eranian <eranian@...gle.com>
>     Cc: Thomas Gleixner <tglx@...utronix.de>
>     Cc: Vince Weaver <vincent.weaver@...ne.edu>
>     Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
>     Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.net
>     Signed-off-by: Ingo Molnar <mingo@...nel.org>

Regards,
Salvatore

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.