CVE-2025-21645 refers to a bug found and fixed in the Linux kernel’s AMD PMC (Platform Management Controller) driver for x86 systems. The problem could cause unbalanced IRQ (interrupt request) wake disables, resulting in kernel warnings and potentially unstable suspend/hibernate behavior.

This post explains the issue, how it happens, and how the kernel code was fixed. There’s also a code snippet of the fix, references, and how you could reproduce the issue on affected systems.

What Was the Problem?

The Linux kernel manages power state transitions (like suspend and hibernate). Some drivers, like the AMD PMC driver and the i8042 keyboard controller, cooperate when changing power states, especially about which IRQs are allowed to wake up the system.

IRQ1 is commonly used for keyboard events (handled by the i8042 driver). During suspend, the i8042 driver may enable IRQ1 as a wakeup source—meaning a keyboard press could wake the machine. But the enable/disable of this wakeup source needs to stay balanced: if you enable it, you have to disable it exactly once.

A bug in the AMD PMC driver was unconditionally disabling IRQ1 wakeup—even when the i8042 driver had never enabled it. This led to the kernel’s "wake_depth" counter for IRQ1 dropping below zero, causing a warning like:

kernel: atkbd serio: Disabling IRQ1 wakeup source to avoid platform firmware bug
kernel: ------------[ cut here ]------------
kernel: Unbalanced IRQ 1 wake disable
kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+x147/x1a

While this warning itself wouldn’t crash your system, unbalanced IRQ handling could cause unexpected wakeup issues.

How Did the Code Work Before?

Both i8042 and AMD PMC drivers provide dev_pm_ops—methods the kernel calls during suspend/resume/etc. But there was a mismatch:

The i8042 suspend handler was only ever called for .suspend.

This meant the PMC driver could end up disabling IRQ1 wakeup even for transitions where i8042 hadn’t enabled it, leading to the warning.


## Exploit/Risk Details

An attacker cannot directly exploit this issue for privilege escalation or code execution. However, a user or admin might encounter unstable hibernate/suspend behavior, especially on laptops using s2idle or certain ACPI features.

In some cases, it could theoretically lead to a system not waking up properly, or to repeated warnings polluting the system logs, which might interfere with diagnosing other issues.

Boot your Linux system (with an affected AMD platform).

2. After boot, directly try to hibernate (S4, usually via systemctl hibernate) without first suspending to s2idle.

The Fix

The kernel patch changes the AMD PMC driver so its suspend handler is only used for .suspend — matching the i8042 behavior. This keeps IRQ1 wakeup enable/disable actions balanced.

Snippet (simplified for clarity)

// Before: PMC suspend handler was registered for multiple events
// DEFINE_SIMPLE_DEV_PM_OPS(amd_pmc_pm_ops, amd_pmc_suspend_handler, ...);

// After: Only register for .suspend, matching i8042
static struct dev_pm_ops amd_pmc_pm_ops = {
    .suspend = amd_pmc_suspend_handler,
    // .freeze and .poweroff not assigned here
};

const struct dev_pm_ops *pm_ops = &amd_pmc_pm_ops;

With this, the AMD PMC driver will only disable IRQ1 wakeup in the same scenarios the i8042 enabled it. No more unbalanced disables, no more WARNs.

Technical Reference

- Patch: platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it
- Linux Kernel commit history for platform/x86/amd/pmc

Conclusion

CVE-2025-21645 was a subtle kernel bug leading to unbalanced IRQ wakeup handling during power events, specific to AMD platforms and impacting suspend/hibernate stability. The fix is simple but crucial, especially on laptops where reliable wakeup is essential.

If you use an affected kernel, update to a version including this patch, especially if you see the warning message in your logs.

Stay current, keep Linux reliable!

*This post is exclusive: if you need to discuss similar kernel issues or deep-dive into Linux ACPI/platform bugs, leave a comment or reach out!*

Timeline

Published on: 01/19/2025 11:15:10 UTC
Last modified on: 05/22/2025 13:15:55 UTC