CVE-2022-49781: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling amd_pmu_enable_all() does: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK> amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu.
AI Analysis
Technical Summary
CVE-2022-49781 is a vulnerability in the Linux kernel's performance monitoring unit (PMU) code specific to AMD processors, particularly in the perf subsystem's handling of non-maskable interrupts (NMIs). The flaw arises from a race condition between the amd_pmu_enable_all() function and the perf NMI handler. Specifically, amd_pmu_enable_all() iterates over active performance events and enables them one by one. However, a perf NMI for another event can interrupt this process. The NMI handler disables and re-enables all events, including the one currently being enabled by amd_pmu_enable_all(). If the re-enabled event has a very low sampling period, it can trigger immediate successive NMIs, causing the event to be throttled and cleared from the active mask and event list by x86_pmu_stop(). When amd_pmu_enable_all() resumes, it attempts to enable an event that has been cleared, resulting in a NULL pointer dereference and a kernel crash. This bug leads to a denial of service (DoS) condition by crashing the kernel due to a NULL pointer dereference triggered by race conditions in PMU event handling. The root cause is the interaction between the perf NMI handler and amd_pmu_enable_all(), which was recently modified to enable Branch Record Store (BRS) support. The suggested fix involves disabling BRS at the start of the NMI handler and re-enabling it upon exit to prevent enabling events that are not yet fully active in hardware, thereby avoiding the race condition. This vulnerability affects Linux kernel versions containing the specified commit hashes and is specific to AMD PMU event handling on x86 architectures.
Potential Impact
For European organizations relying on Linux systems with AMD processors, this vulnerability can cause unexpected kernel crashes leading to system downtime and denial of service. This is particularly critical for infrastructure providers, cloud services, and enterprises running performance monitoring or profiling tools that utilize the perf subsystem. The impact includes potential disruption of critical services, loss of availability, and operational interruptions. While the vulnerability does not directly lead to privilege escalation or data leakage, the resulting kernel panic can affect system stability and availability, which is crucial for sectors such as finance, healthcare, telecommunications, and government services in Europe. Systems performing intensive performance monitoring or profiling are at higher risk. Additionally, the lack of known exploits in the wild currently reduces immediate risk, but the complexity of the bug and its kernel-level nature mean that exploitation could be automated in the future, increasing risk to European organizations that do not patch promptly.
Mitigation Recommendations
European organizations should promptly apply the Linux kernel patches that address this race condition in the perf subsystem. Since the vulnerability arises from a race condition in the AMD PMU event handling, updating to a kernel version that includes the fix or backporting the patch is essential. Organizations should audit their use of perf and related performance monitoring tools, especially those configured with low sampling periods or aggressive profiling settings, as these increase the likelihood of triggering the bug. Temporarily disabling Branch Record Store (BRS) support in the perf NMI handler, if feasible, can serve as a workaround until patches are applied. Additionally, monitoring kernel logs for perf-related errors or crashes can help detect attempts to trigger this vulnerability. For critical systems, consider isolating performance monitoring workloads or limiting access to perf interfaces to trusted administrators to reduce the attack surface. Finally, ensure robust kernel crash recovery and system monitoring to minimize downtime in case of unexpected crashes.
Affected Countries
Germany, France, United Kingdom, Netherlands, Italy, Spain, Poland, Sweden, Belgium, Finland
CVE-2022-49781: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling amd_pmu_enable_all() does: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK> amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu.
AI-Powered Analysis
Technical Analysis
CVE-2022-49781 is a vulnerability in the Linux kernel's performance monitoring unit (PMU) code specific to AMD processors, particularly in the perf subsystem's handling of non-maskable interrupts (NMIs). The flaw arises from a race condition between the amd_pmu_enable_all() function and the perf NMI handler. Specifically, amd_pmu_enable_all() iterates over active performance events and enables them one by one. However, a perf NMI for another event can interrupt this process. The NMI handler disables and re-enables all events, including the one currently being enabled by amd_pmu_enable_all(). If the re-enabled event has a very low sampling period, it can trigger immediate successive NMIs, causing the event to be throttled and cleared from the active mask and event list by x86_pmu_stop(). When amd_pmu_enable_all() resumes, it attempts to enable an event that has been cleared, resulting in a NULL pointer dereference and a kernel crash. This bug leads to a denial of service (DoS) condition by crashing the kernel due to a NULL pointer dereference triggered by race conditions in PMU event handling. The root cause is the interaction between the perf NMI handler and amd_pmu_enable_all(), which was recently modified to enable Branch Record Store (BRS) support. The suggested fix involves disabling BRS at the start of the NMI handler and re-enabling it upon exit to prevent enabling events that are not yet fully active in hardware, thereby avoiding the race condition. This vulnerability affects Linux kernel versions containing the specified commit hashes and is specific to AMD PMU event handling on x86 architectures.
Potential Impact
For European organizations relying on Linux systems with AMD processors, this vulnerability can cause unexpected kernel crashes leading to system downtime and denial of service. This is particularly critical for infrastructure providers, cloud services, and enterprises running performance monitoring or profiling tools that utilize the perf subsystem. The impact includes potential disruption of critical services, loss of availability, and operational interruptions. While the vulnerability does not directly lead to privilege escalation or data leakage, the resulting kernel panic can affect system stability and availability, which is crucial for sectors such as finance, healthcare, telecommunications, and government services in Europe. Systems performing intensive performance monitoring or profiling are at higher risk. Additionally, the lack of known exploits in the wild currently reduces immediate risk, but the complexity of the bug and its kernel-level nature mean that exploitation could be automated in the future, increasing risk to European organizations that do not patch promptly.
Mitigation Recommendations
European organizations should promptly apply the Linux kernel patches that address this race condition in the perf subsystem. Since the vulnerability arises from a race condition in the AMD PMU event handling, updating to a kernel version that includes the fix or backporting the patch is essential. Organizations should audit their use of perf and related performance monitoring tools, especially those configured with low sampling periods or aggressive profiling settings, as these increase the likelihood of triggering the bug. Temporarily disabling Branch Record Store (BRS) support in the perf NMI handler, if feasible, can serve as a workaround until patches are applied. Additionally, monitoring kernel logs for perf-related errors or crashes can help detect attempts to trigger this vulnerability. For critical systems, consider isolating performance monitoring workloads or limiting access to perf interfaces to trusted administrators to reduce the attack surface. Finally, ensure robust kernel crash recovery and system monitoring to minimize downtime in case of unexpected crashes.
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-04-16T07:17:33.806Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d982cc4522896dcbe4b79
Added to database: 5/21/2025, 9:09:00 AM
Last enriched: 6/30/2025, 1:27:28 AM
Last updated: 8/14/2025, 6:48:53 PM
Views: 16
Related Threats
CVE-2025-8991: Business Logic Errors in linlinjava litemall
MediumCVE-2025-8990: SQL Injection in code-projects Online Medicine Guide
MediumCVE-2025-8940: Buffer Overflow in Tenda AC20
HighCVE-2025-8939: Buffer Overflow in Tenda AC20
HighCVE-2025-50518: n/a
HighActions
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.