Bug 1025626 (CVE-2017-6001)

Summary: VUL-0: CVE-2017-6001: kernel-source: Incomplete fix for CVE-2016-6786: perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
Product: [Novell Products] SUSE Security Incidents Reporter: Mikhail Kasimov <mikhail.kasimov>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED WONTFIX QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: astieger, bpetkov, gabriele.sonnu, mbenes, meissner
Version: unspecified   
Target Milestone: unspecified   
Hardware: Other   
OS: Other   
URL: https://smash.suse.de/issue/180623/
Whiteboard: CVSSv2:NVD:CVE-2017-6001:7.6:(AV:N/AC:H/Au:N/C:C/I:C/A:C) CVSSv2:SUSE:CVE-2017-6001:6.2:(AV:L/AC:H/Au:N/C:C/I:C/A:C)
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 1015160    

Description Mikhail Kasimov 2017-02-16 10:04:13 UTC
Ref: http://seclists.org/oss-sec/2017/q1/446

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


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 ->

Commit message reads as:

    commit 321027c1fe77f892f4ea07846aeae08cefbbb290
    Author: Peter Zijlstra <peterz () infradead 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 () google com>
        Signed-off-by: Peter Zijlstra (Intel) <peterz () infradead org>
        Cc: Alexander Shishkin <alexander.shishkin () linux intel com>
        Cc: Arnaldo Carvalho de Melo <acme () kernel org>
        Cc: Arnaldo Carvalho de Melo <acme () redhat com>
        Cc: Jiri Olsa <jolsa () redhat com>
        Cc: Kees Cook <keescook () chromium org>
        Cc: Linus Torvalds <torvalds () linux-foundation org>
        Cc: Min Chong <mchong () google com>
        Cc: Peter Zijlstra <peterz () infradead org>
        Cc: Stephane Eranian <eranian () google com>
        Cc: Thomas Gleixner <tglx () linutronix de>
        Cc: Vince Weaver <vincent.weaver () maine 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 () kernel org>


Comment 1 Swamp Workflow Management 2017-02-16 23:00:33 UTC
bugbot adjusting priority
Comment 3 Marcus Meissner 2017-03-06 10:48:42 UTC
we so far did not backport the other fix, so we are not affected.

Tony, please backport both and mention both CVEs.
Comment 4 Tony Jones 2017-03-09 00:05:06 UTC
(In reply to Marcus Meissner from comment #3)
> we so far did not backport the other fix, so we are not affected.
> Tony, please backport both and mention both CVEs.

I'll look but these changes are stacked on top of so many prior locking changes that would need to be ported that it's complex.
Comment 5 Gabriele Sonnu 2022-03-31 08:09:03 UTC
Since we decided to not backport the other fix (bsc#1015160), we won't backport this one either. Closing as WONTFIX.