CVE-2022-49607: Vulnerability in Linux Linux
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.
AI Analysis
Technical Summary
CVE-2022-49607 is a concurrency vulnerability identified in the Linux kernel's performance monitoring subsystem, specifically within the perf core component. The flaw arises from a data race condition between two kernel functions: perf_event_set_output() and perf_mmap_close(). These functions manage the attachment and detachment of ring buffers (rb) used for performance event monitoring. The race occurs because perf_event_set_output() and perf_mmap_close() manipulate shared data structures without adequate synchronization, leading to inconsistent states. Specifically, perf_mmap_close() may decrement the mmap_count and detach a ring buffer while perf_event_set_output() concurrently attaches a new event to the same ring buffer. This results in a scenario where an event (e1) is attached to an unmapped ring buffer (rb), causing the perf_mmap() function to enter an infinite loop when it attempts to access this invalid state. The root cause is the lack of proper locking: perf_event_set_output() holds e1->mmap_mutex, and perf_mmap_close() holds e2->mmap_mutex, but no mechanism ensures serialization between these two mutexes, allowing the race. The fix involves modifying perf_event_set_output() to acquire both e1->mmap_mutex and e2->mmap_mutex, ensuring proper serialization and preventing the race. Additionally, the perf_mmap() loop is adjusted to detach the ring buffer directly, avoiding waiting on concurrent perf_mmap_close() operations. This vulnerability affects multiple Linux kernel versions identified by specific commit hashes, indicating it is present in certain development or stable branches. No known exploits are reported in the wild, and no CVSS score has been assigned yet. The issue primarily impacts system stability and reliability by causing kernel-level infinite loops, potentially leading to denial of service (DoS) conditions on affected systems.
Potential Impact
For European organizations, this vulnerability poses a risk primarily to systems running vulnerable Linux kernel versions with perf enabled, especially those relying on performance monitoring tools for diagnostics or security monitoring. The infinite loop caused by the race condition can lead to kernel hangs or crashes, resulting in denial of service. This can disrupt critical infrastructure, cloud services, and enterprise servers that depend on Linux for stable operation. Organizations in sectors such as finance, telecommunications, manufacturing, and government, which often use Linux-based systems for their backend services, could experience service outages or degraded performance. Additionally, the inability to properly monitor performance events due to this flaw could hinder incident response and system diagnostics, indirectly affecting security posture. While there is no evidence of privilege escalation or data leakage, the availability impact alone can be significant in environments requiring high uptime and reliability. The absence of known exploits suggests the threat is currently low but could increase if attackers develop techniques to trigger the race condition deliberately.
Mitigation Recommendations
European organizations should prioritize updating their Linux kernels to versions where this race condition is fixed, ensuring that perf_event_set_output() and perf_mmap_close() are properly synchronized. Kernel updates should be applied promptly following vendor advisories. For environments where immediate patching is challenging, consider disabling the perf subsystem if it is not essential, as this reduces the attack surface. System administrators should audit their kernel versions and perf usage, especially on critical servers and infrastructure devices. Monitoring kernel logs for unusual perf-related errors or hangs can provide early warning signs. Additionally, implementing robust system monitoring and automated recovery mechanisms can mitigate the impact of potential hangs caused by this vulnerability. For organizations using custom or embedded Linux distributions, coordinate with vendors or maintainers to backport the fix. Finally, incorporate this vulnerability into vulnerability management programs and penetration testing to validate remediation effectiveness.
Affected Countries
Germany, France, United Kingdom, Netherlands, Italy, Spain, Sweden, Poland, Belgium, Finland
CVE-2022-49607: Vulnerability in Linux Linux
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.
AI-Powered Analysis
Technical Analysis
CVE-2022-49607 is a concurrency vulnerability identified in the Linux kernel's performance monitoring subsystem, specifically within the perf core component. The flaw arises from a data race condition between two kernel functions: perf_event_set_output() and perf_mmap_close(). These functions manage the attachment and detachment of ring buffers (rb) used for performance event monitoring. The race occurs because perf_event_set_output() and perf_mmap_close() manipulate shared data structures without adequate synchronization, leading to inconsistent states. Specifically, perf_mmap_close() may decrement the mmap_count and detach a ring buffer while perf_event_set_output() concurrently attaches a new event to the same ring buffer. This results in a scenario where an event (e1) is attached to an unmapped ring buffer (rb), causing the perf_mmap() function to enter an infinite loop when it attempts to access this invalid state. The root cause is the lack of proper locking: perf_event_set_output() holds e1->mmap_mutex, and perf_mmap_close() holds e2->mmap_mutex, but no mechanism ensures serialization between these two mutexes, allowing the race. The fix involves modifying perf_event_set_output() to acquire both e1->mmap_mutex and e2->mmap_mutex, ensuring proper serialization and preventing the race. Additionally, the perf_mmap() loop is adjusted to detach the ring buffer directly, avoiding waiting on concurrent perf_mmap_close() operations. This vulnerability affects multiple Linux kernel versions identified by specific commit hashes, indicating it is present in certain development or stable branches. No known exploits are reported in the wild, and no CVSS score has been assigned yet. The issue primarily impacts system stability and reliability by causing kernel-level infinite loops, potentially leading to denial of service (DoS) conditions on affected systems.
Potential Impact
For European organizations, this vulnerability poses a risk primarily to systems running vulnerable Linux kernel versions with perf enabled, especially those relying on performance monitoring tools for diagnostics or security monitoring. The infinite loop caused by the race condition can lead to kernel hangs or crashes, resulting in denial of service. This can disrupt critical infrastructure, cloud services, and enterprise servers that depend on Linux for stable operation. Organizations in sectors such as finance, telecommunications, manufacturing, and government, which often use Linux-based systems for their backend services, could experience service outages or degraded performance. Additionally, the inability to properly monitor performance events due to this flaw could hinder incident response and system diagnostics, indirectly affecting security posture. While there is no evidence of privilege escalation or data leakage, the availability impact alone can be significant in environments requiring high uptime and reliability. The absence of known exploits suggests the threat is currently low but could increase if attackers develop techniques to trigger the race condition deliberately.
Mitigation Recommendations
European organizations should prioritize updating their Linux kernels to versions where this race condition is fixed, ensuring that perf_event_set_output() and perf_mmap_close() are properly synchronized. Kernel updates should be applied promptly following vendor advisories. For environments where immediate patching is challenging, consider disabling the perf subsystem if it is not essential, as this reduces the attack surface. System administrators should audit their kernel versions and perf usage, especially on critical servers and infrastructure devices. Monitoring kernel logs for unusual perf-related errors or hangs can provide early warning signs. Additionally, implementing robust system monitoring and automated recovery mechanisms can mitigate the impact of potential hangs caused by this vulnerability. For organizations using custom or embedded Linux distributions, coordinate with vendors or maintainers to backport the fix. Finally, incorporate this vulnerability into vulnerability management programs and penetration testing to validate remediation effectiveness.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2025-02-26T02:21:30.417Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9821c4522896dcbdd6e8
Added to database: 5/21/2025, 9:08:49 AM
Last enriched: 6/28/2025, 12:42:35 AM
Last updated: 7/25/2025, 10:11:05 AM
Views: 10
Related Threats
CVE-2025-8815: Path Traversal in 猫宁i Morning
MediumCVE-2025-8814: Cross-Site Request Forgery in atjiu pybbs
MediumCVE-2025-8813: Open Redirect in atjiu pybbs
MediumCVE-2025-8812: Cross Site Scripting in atjiu pybbs
MediumCVE-2025-8811: SQL Injection in code-projects Simple Art Gallery
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.