platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it
Wakeup for IRQ1 should be disabled only in cases where i8042 had
actually enabled it, otherwise "wake_depth" for this IRQ will try to
drop below zero and there will be an unpleasant WARN() logged:
kernel: atkbd serio0: 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+0x147/0x1a0
The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops
which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and
.poweroff handlers. i8042_pm_suspend(), however, is only set as
the .suspend handler.
Fix the issue by call PMC suspend handler only from the same set of
dev_pm_ops handlers as i8042_pm_suspend(), which currently means just
the .suspend handler.
To reproduce this issue try hibernating (S4) the machine after a fresh boot
without putting it into s2idle first.
[ij: edited the commit message.]
Metrics
Affected Vendors & Products
Source | ID | Title |
---|---|---|
![]() |
DLA-4271-1 | linux-6.1 security update |
![]() |
DSA-5925-1 | linux security update |
![]() |
EUVD-2025-2594 | In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wake_depth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged: kernel: atkbd serio0: 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+0x147/0x1a0 The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and .poweroff handlers. i8042_pm_suspend(), however, is only set as the .suspend handler. Fix the issue by call PMC suspend handler only from the same set of dev_pm_ops handlers as i8042_pm_suspend(), which currently means just the .suspend handler. To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first. [ij: edited the commit message.] |
![]() |
USN-7379-1 | Linux kernel vulnerabilities |
![]() |
USN-7379-2 | Linux kernel (Raspberry Pi) vulnerabilities |
![]() |
USN-7380-1 | Linux kernel (Low Latency) vulnerabilities |
![]() |
USN-7381-1 | Linux kernel (Low Latency) vulnerabilities |
![]() |
USN-7382-1 | Linux kernel (OEM) vulnerabilities |
![]() |
USN-7513-1 | Linux kernel vulnerabilities |
![]() |
USN-7513-2 | Linux kernel (Real-time) vulnerabilities |
![]() |
USN-7513-3 | Linux kernel vulnerabilities |
![]() |
USN-7513-4 | Linux kernel (HWE) vulnerabilities |
![]() |
USN-7513-5 | Linux kernel (Oracle) vulnerabilities |
![]() |
USN-7514-1 | Linux kernel (NVIDIA) vulnerabilities |
![]() |
USN-7515-1 | Linux kernel (GKE) vulnerabilities |
![]() |
USN-7515-2 | Linux kernel vulnerabilities |
![]() |
USN-7522-1 | Linux kernel (Azure, N-Series) vulnerabilities |
![]() |
USN-7523-1 | Linux kernel (Raspberry Pi Real-time) vulnerabilities |
![]() |
USN-7524-1 | Linux kernel (Raspberry Pi) vulnerabilities |
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Thu, 16 Oct 2025 19:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Linux
Linux linux Kernel |
|
Weaknesses | NVD-CWE-noinfo | |
CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.13:rc6:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.2:-:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.2:rc6:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.2:rc7:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.2:rc8:*:*:*:*:*:* |
|
Vendors & Products |
Linux
Linux linux Kernel |
|
Metrics |
cvssV3_1
|
cvssV3_1
|
Thu, 22 May 2025 13:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
|
Thu, 13 Feb 2025 01:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Weaknesses | CWE-20 | |
Metrics |
cvssV3_1
|
cvssV3_1
|
Mon, 20 Jan 2025 14:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Sun, 19 Jan 2025 10:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wake_depth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged: kernel: atkbd serio0: 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+0x147/0x1a0 The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and .poweroff handlers. i8042_pm_suspend(), however, is only set as the .suspend handler. Fix the issue by call PMC suspend handler only from the same set of dev_pm_ops handlers as i8042_pm_suspend(), which currently means just the .suspend handler. To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first. [ij: edited the commit message.] | |
Title | platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it | |
References |
|

Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-05-22T12:40:04.881Z
Reserved: 2024-12-29T08:45:45.728Z
Link: CVE-2025-21645

No data.

Status : Analyzed
Published: 2025-01-19T11:15:10.090
Modified: 2025-10-16T19:17:53.183
Link: CVE-2025-21645


No data.