CVE-2022-49607: linux kernel — Fix

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.

Is your site exposed to CVE-2022-49607?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

4.7

MEDIUM

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Weakness Type (CWE)

CWE-362 CWE-362

Affected Products

Vendor	Product	Versions
linux	linux_kernel	3.2.49 — 3.3
linux	linux_kernel	3.4.52 — 3.5
linux	linux_kernel	3.9.8 — 4.9.325
linux	linux_kernel	4.10 — 4.14.290
linux	linux_kernel	4.15 — 4.19.254
linux	linux_kernel	4.20 — 5.4.208
linux	linux_kernel	5.5 — 5.10.134
linux	linux_kernel	5.11 — 5.15.58
linux	linux_kernel	5.16 — 5.18.15
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All

References

Advisories & Patches

https://git.kernel.org/stable/c/17f5417194136517ee9bbd6511249e5310e5617c https://git.kernel.org/stable/c/3bbd868099287ff9027db59029b502fcfa2202a0 https://git.kernel.org/stable/c/43128b3eee337824158f34da6648163d2f2fb937 https://git.kernel.org/stable/c/68e3c69803dada336893640110cb87221bb01dcf https://git.kernel.org/stable/c/98c3c8fd0d4c560e0f8335b79c407bbf7fc9462c https://git.kernel.org/stable/c/a9391ff7a7c5f113d6f2bf6621d49110950de49c https://git.kernel.org/stable/c/da3c256e2d0ebc87c7db0c605c9692b6f1722074 https://git.kernel.org/stable/c/f836f9ac95df15f1e0af4beb0ec20021e8c91998

Frequently Asked Questions

What is CVE-2022-49607? +

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. It has a CVSS v3.1 base score of 4.7 (MEDIUM).

How severe is CVE-2022-49607? +

CVE-2022-49607 has a CVSS v3.1 score of 4.7 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance.

What products are affected by CVE-2022-49607? +

CVE-2022-49607 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.

How do I check if I'm vulnerable to CVE-2022-49607? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-41458

OwnTone Server versions 28.4 through 29.0 contain a race condition vulnerability in the DAAP login handler that allows unauthenticated attackers …

CVE-2025-13036

An authentication bypass security issue exists within FactoryTalk Historian Site Edition. By continually sending requests to the login endpoint, an …

CVE-2025-15630

A race condition exists in the cloud-based Omada device adoption process when an attacker may be able to interact with …

CVE-2025-0372

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in HYPR Passwordless on Windows allows Privilege Escalation.This issue …

CVE-2025-59052

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Angular uses a …

CVE-2024-47534

go-tuf is a Go implementation of The Update Framework (TUF). The go-tuf client inconsistently traces the delegations. For example, if …

CVE-2022-49607