CVE-2022-49607 in Linux
Summary
by MITRE • 02/26/2025
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 04/17/2025
This vulnerability exists in the Linux kernel's performance monitoring subsystem, specifically within the perf core functionality that manages event tracking and ring buffer operations. The issue manifests as a data race condition between two critical functions: perf_event_set_output() and perf_mmap_close(). This race condition occurs when multiple CPU cores attempt to concurrently modify the same ring buffer attachment state, creating a scenario where event tracking becomes corrupted and eventually leads to infinite loops during memory mapping operations. The vulnerability is particularly dangerous because it affects the fundamental performance monitoring capabilities of the kernel, potentially causing system instability and denial of service conditions.
The technical flaw stems from insufficient synchronization between the two competing operations that modify ring buffer event lists. When perf_mmap_close() executes on one CPU core, it decrements the mmap_count atomic counter and determines whether to detach remaining events. Meanwhile, perf_event_set_output() on another CPU core attempts to attach a new event to the same ring buffer. The race condition occurs because the functions do not properly serialize access to the shared ring buffer resources, creating a temporal window where an event gets attached to a ring buffer that is in the process of being unmapped. This creates a circular dependency where the event remains attached to an unmapped buffer, causing subsequent perf_mmap() operations to enter infinite loops as they attempt to validate buffer mappings.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially compromise system stability and availability. When the infinite loop occurs in perf_mmap(), the system may experience complete lockup of performance monitoring functions, making it impossible to collect accurate performance data or debug system issues. This vulnerability affects any system running the affected Linux kernel version where performance monitoring is actively used, particularly impacting servers and systems that rely heavily on performance profiling and monitoring tools. The race condition can be triggered through normal system operations involving concurrent perf event management, making it particularly insidious as it may not require malicious input to exploit.
The fix implemented addresses the root cause by modifying perf_event_set_output() to acquire locks on both the source and destination ring buffer mutexes, ensuring proper serialization of access to shared resources. Additionally, the perf_mmap() loop was enhanced to directly detach ring buffers rather than waiting for the concurrent perf_mmap_close() operation to complete, which eliminates the dependency on proper lock ordering. This approach aligns with common security practices for preventing race conditions in concurrent systems and follows the principle of least privilege by ensuring proper resource access control. The solution also corresponds to CWE-362, which specifically addresses concurrent execution issues and race conditions, and relates to ATT&CK technique T1059.001 for system execution flaws that can lead to denial of service conditions. Organizations should apply the kernel patch immediately to prevent exploitation, as the vulnerability can be triggered through legitimate system operations and does not require special privileges to exploit.