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>] [day] [month] [year] [list]
Message-ID: <2025022612-CVE-2022-49607-bfc4@gregkh>
Date: Wed, 26 Feb 2025 03:22:50 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2022-49607: perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()

Description
===========

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

perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()

Yang Jihing reported a race between perf_event_set_output() and
perf_mmap_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 perf_mmap_close() holds e2->mmap_mutex, while the attach
in perf_event_set_output() holds e1->mmap_mutex. As such there is no
serialization to avoid this race.

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

The Linux kernel CVE team has assigned CVE-2022-49607 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.10 with commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b and fixed in 4.9.325 with commit 3bbd868099287ff9027db59029b502fcfa2202a0
	Issue introduced in 3.10 with commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b and fixed in 4.14.290 with commit f836f9ac95df15f1e0af4beb0ec20021e8c91998
	Issue introduced in 3.10 with commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b and fixed in 4.19.254 with commit 17f5417194136517ee9bbd6511249e5310e5617c
	Issue introduced in 3.10 with commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b and fixed in 5.4.208 with commit 98c3c8fd0d4c560e0f8335b79c407bbf7fc9462c
	Issue introduced in 3.10 with commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b and fixed in 5.10.134 with commit 43128b3eee337824158f34da6648163d2f2fb937
	Issue introduced in 3.10 with commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b and fixed in 5.15.58 with commit da3c256e2d0ebc87c7db0c605c9692b6f1722074
	Issue introduced in 3.10 with commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b and fixed in 5.18.15 with commit a9391ff7a7c5f113d6f2bf6621d49110950de49c
	Issue introduced in 3.10 with commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b and fixed in 5.19 with commit 68e3c69803dada336893640110cb87221bb01dcf
	Issue introduced in 3.2.49 with commit 2487f0db30527032c4d56fc2d0b1a240fe89fef8
	Issue introduced in 3.4.52 with commit 703197b61d05f5edae54bad3256901c5a5c8794c
	Issue introduced in 3.9.8 with commit c52217e88ae0f3a4ae00562d86e338f8f85969b4

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49607
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	kernel/events/core.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/3bbd868099287ff9027db59029b502fcfa2202a0
	https://git.kernel.org/stable/c/f836f9ac95df15f1e0af4beb0ec20021e8c91998
	https://git.kernel.org/stable/c/17f5417194136517ee9bbd6511249e5310e5617c
	https://git.kernel.org/stable/c/98c3c8fd0d4c560e0f8335b79c407bbf7fc9462c
	https://git.kernel.org/stable/c/43128b3eee337824158f34da6648163d2f2fb937
	https://git.kernel.org/stable/c/da3c256e2d0ebc87c7db0c605c9692b6f1722074
	https://git.kernel.org/stable/c/a9391ff7a7c5f113d6f2bf6621d49110950de49c
	https://git.kernel.org/stable/c/68e3c69803dada336893640110cb87221bb01dcf

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ