CVE-2022-49607

In the Linux kernel, the following vulnerability has been resolved:

perf/core: Fix data race between perfeventsetoutput() and perfmmap_close()

Yang Jihing reported a race between perfeventsetoutput() and perfmmap_close():

CPU1                    CPU2

perf_mmap_close(e2)
  if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0
    detach_rest = true

                    ioctl(e1, IOC_SET_OUTPUT, e2)
                      perf_event_set_output(e1, e2)

  ...
  list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry)
    ring_buffer_attach(e, NULL);
    // e1 isn't yet added and
    // therefore not detached

                        ring_buffer_attach(e1, e2->rb)
                          list_add_rcu(&e1->rb_entry,
                               &e2->rb->event_list)

After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more:

again:
    mutex_lock(&e->mmap_mutex);
    if (event->rb) {
        ...
        if (!atomic_inc_not_zero(&e->rb->mmap_count)) {
            ...
            mutex_unlock(&e->mmap_mutex);
            goto again;
        }
    }

The loop in perfmmapclose() holds e2->mmapmutex, while the attach in perfeventsetoutput() holds e1->mmap_mutex. As such there is no serialization to avoid this race.

Change perfeventsetoutput() to take both e1->mmapmutex and e2->mmapmutex to alleviate that problem. Additionally, have the loop in perfmmap() detach the rb directly, this avoids having to wait for the concurrent perfmmapclose() to get around to doing it to make progress.