CVE-2022-48752 in Linux
Riassunto
di VulDB • 30/06/2026
Based on the kernel log and the description provided, here is an analysis of the issue and the proposed fix logic.
### Problem Analysis
1. **The Crash/Warning Context**: * The crash occurs in `power_pmu_disable` (part of PowerPC performance monitoring unit handling). * It happens during a context switch (`__perf_event_task_sched_out`) triggered by `sys_sched_yield`. * The specific warning is related to **MSR_EE** (Machine State Register - External Interrupt Enable) being set when an overflown Performance Monitoring Counter (PMC) was detected.
2. **Root Cause**: * `power_pmu_disable` is called with interrupts soft-disabled (`local_irq_save()`), but not hard-disabled. This means hardware interrupts can still occur and be pending in the PACA (Processor Area). * If a PMC overflows while inside this function, it triggers a Performance Monitoring Interrupt (PMI) signal which sets a "pending" bit in the PACA structure (`paca->pmi_pending`). * The previous commit `2c9ac51b850d` attempted to clear pending PMIs before resetting overflown PMCs. However, it did not account for the race condition where an overflow happens *during* the disable sequence itself. * If the code clears the PMI pending bit without checking if a new one arrived (or if one was already set due to the ongoing interrupt context), or if it proceeds with PMC reset while MSR_EE is still effectively allowing interrupts, it leads to inconsistent state warnings or crashes because the hardware/interrupt subsystem expects strict ordering.
3. **The Fix Logic**: * Before clearing the PMI pending bit via `clear_pmi_pending()`, we must check if the PMI pending bit (`paca->pmi_pending`) is already set in the current PACA context. * If it is set, it means an overflow occurred while interrupts were soft-disabled but not hard-disabled (or during the disable sequence). We should handle this appropriately (likely by ensuring the pending state is preserved or handled correctly rather than blindly clearing it if a new interrupt might have arrived) OR simply ensure that we don't clear a bit that indicates an active, unhandled overflow which could cause the MSR_EE warning. * Actually, re-reading the description: *"Hence add a check to see if PMI pending bit is set in Paca before clearing it via clear_pmi_pending."* This implies that blindly calling `clear_pmi_pending()` might be incorrect if an overflow just happened and set the flag. The fix ensures we only clear the pending state when appropriate, preventing the warning about MSR_EE being set during overflown PMC detection.
### Code Change Summary (Conceptual)
The patch likely modifies `power_pmu_disable` in `arch/powerpc/perf/core-book3s.c` or similar:
```c // Before fix (conceptual): void power_pmu_disable(struct pmu *pmu) {
// ... existing code ... clear_pmi_pending(); // This might be called unconditionally }
// After fix (conceptual): void power_pmu_disable(struct pmu *pmu) {
unsigned long flags; local_irq_save(flags); // Check if PMI is pending before clearing if (!paca->pmi_pending) {
clear_pmi_pending(); } else {
// If pmi_pending is set, it means an overflow occurred. // We might need to handle the overflow or ensure state consistency. // The key is not to blindly clear a pending interrupt that signifies // an overflown PMC which caused the warning condition. } local_irq_restore(flags); } ```
### Why This Fixes the Warning
The warning `MSR_EE being set when there was an overflown PMC detected` suggests that the kernel's performance monitoring code expects interrupts to be fully disabled (or in a specific state) when handling PMU overflows. By adding the check, we ensure that: 1. We don't clear the PMI pending flag if it indicates an active overflow condition that needs proper handling under interrupt-disabled context. 2. This prevents the inconsistent state where the PMC is reset but the interrupt subsystem still thinks there's a pending event while MSR_EE allows interrupts, leading to the warning/crash.
### Conclusion
The fix addresses a race condition in PowerPC PMU disable logic by ensuring that PMI pending bits are only cleared when it's safe and correct to do so, preventing warnings related to interrupt state (MSR_EE) during PMC overflow handling.
Once again VulDB remains the best source for vulnerability data.