kernel/git/stable/linux.git/drivers/acpi, branch linux-rolling-lts

ACPI: TAD: Add locking around AML evaluations

2026-09-11T09:49:38+00:00

[ Upstream commit a3df8bbe0a704fa5c1609b9666b594f350558fe0 ] In the ACPI TAD driver, there are hidden assumptions that the ACPI control methods used by it will not be evaluated concurrently due to ACPICA namespace and interpreter locking. However, that may not be the case since ACPICA may drop and re-acquire the namespace and interpreter locks during the evaluation of a given object in a few cases, including the one in which the AML in question sleeps causing acpi_ex_system_do_sleep() to be called. In that case, the evaluation of one control method may be started while the evaluation of another one is still in progress. For this reason, add a global lock to the ACPI TAD driver and acquire it every time before evaluating an ACPI control method, except for the initial evaluation of _GCP in acpi_tad_probe(). Fixes: 95c513ec84f7 ("ACPI: Add Time and Alarm Device (TAD) driver") Cc: All applicable Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/12951141.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ACPI: TAD: Rearrange RT data validation checking

2026-09-11T09:49:38+00:00

[ Upstream commit 3329a1416c3350449081ca5daaa94802a65b2992 ] Move RT data validation checks from acpi_tad_set_real_time() to a separate function called acpi_tad_rt_is_invalid() and use it also in acpi_tad_get_real_time() to validate data coming from the platform firmware. Also make acpi_tad_set_real_time() return -EINVAL when the RT data passed to it is invalid (instead of -ERANGE which is somewhat confusing) and introduce ACPI_TAD_TZ_UNSPEC to represent the "unspecified timezone" value. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3409319.aeNJFYEL58@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ACPI: x86/rtc-cmos: Use platform device for driver binding

2026-09-11T09:49:38+00:00

[ Upstream commit 2a78e42104444f948698f1225deaf515e9b7224d ] Modify the rtc-cmos driver to bind to a platform device on systems with ACPI via acpi_match_table and advertise the CMOST RTC ACPI device IDs for driver auto-loading. Note that adding the requisite device IDs to it and exposing them via MODULE_DEVICE_TABLE() is sufficient for this purpose. Since the ACPI device IDs in question are the same as for the CMOS RTC ACPI scan handler, put them into a common header file and use the definition from there in both places. Additionally, to prevent a PNP device from being created for the CMOS RTC if a platform one is present already, make is_cmos_rtc_device() check cmos_rtc_platform_device_present introduced previously. Signed-off-by: Rafael J. Wysocki Acked-by: Alexandre Belloni Link: https://patch.msgid.link/13969123.uLZWGnKmhe@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ACPI: x86: cmos_rtc: Create a CMOS RTC platform device

2026-09-11T09:49:38+00:00

[ Upstream commit 1ae2f435350ec05224a39995c3a680aa6fdae5a5 ] Make the CMOS RTC ACPI scan handler create a platform device that will be used subsequently by rtc-cmos for driver binding on x86 systems with ACPI and update add_rtc_cmos() to skip registering a fallback platform device for the CMOS RTC when the above one has been registered. Signed-off-by: Rafael J. Wysocki Acked-by: Dave Hansen # x86 Link: https://patch.msgid.link/1962427.tdWV9SEqCh@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ACPI: CPPC: Reject desired_perf reads on _CPC revision 4+

2026-09-11T09:49:38+00:00

[ Upstream commit df5a1d4a8cdfda20eb2581a85e81c7d436866534 ] When CPPC feedback counters cannot provide a usable sample, cppc-cpufreq calls cppc_get_desired_perf() because some platforms repurpose Desired Performance to report actual delivered performance. ACPI 6.5 defines _CPC revision 3 and lists Read/Write as the Optional Attribute of Desired Performance. ACPI 6.6 advances _CPC to revision 4 and lists only Write, so invoking that workaround for revision 4 or later would require a register read that the interface no longer specifies. Make cppc_get_desired_perf() return -EOPNOTSUPP for _CPC revision 4 or later. Use the revision retained in the per-CPU CPC descriptor rather than the platform-wide FADT revision. The _CPC revision may still not accurately describe the implemented register semantics. If a nominally revision 3 platform implements a non-readable Desired Performance register, a read may return zero and make cppc_cpufreq_get_rate() report 0 kHz. Treat a zero read as unusable and fall back to the cached OSPM request, just as for a failed read. Fixes: c47195631960 ("cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged") Cc: stable@vger.kernel.org Suggested-by: Sumit Gupta Signed-off-by: Christian Loehle Link: https://patch.msgid.link/20260803203531.1268651-2-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki [ preserved the raw firmware revision while limiting parsing to the v3-sized register prefix ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ACPI: pfr_update: fix stack buffer overflow in query_capability()

2026-09-07T15:22:35+00:00

commit ced45be0073a8a31b30b4a7f68cd3a15734515de upstream. query_capability() copies four ACPI buffer objects returned by the firmware _DSM into fixed-size u8[16] fields in struct pfru_update_cap_info using memcpy with the firmware-supplied length: memcpy(&cap_hdr->code_type, elements[CAP_CODE_TYPE_IDX].buffer.pointer, elements[CAP_CODE_TYPE_IDX].buffer.length); The same pattern repeats for drv_type, platform_id, and oem_id. If the firmware returns buffer.length > 16 for any of these fields, memcpy writes past the destination array. struct pfru_update_cap_info is stack-allocated in pfru_ioctl(). Confirmed with KASAN on 7.2-rc6: three stack-out-of-bounds reports are generated when a DSM returns 64-byte buffers, with writes reaching 44 bytes past the end of cap_hdr's [64, 156) frame window into adjacent stack redzones. Introduce a helper pointer to out_obj->package.elements and use it to validate each buffer length against its destination field size before copying, returning -EINVAL if the firmware supplies an oversized buffer. Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver") Cc: All applicable Signed-off-by: Anirudh Prasad Link: https://patch.msgid.link/1a001e1fee9.637da6dc3533246.238498880682901704@a0rg.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: APEI: GHES: fix ARM section length accounting after header

2026-09-07T15:22:35+00:00

commit 903308ea40adf0577d82eab69882faf8836326ce upstream. In ghes_handle_arm_hw_error(), after skipping the cper_sec_proc_arm header with (err + 1), the remaining length was reduced by sizeof(err) (pointer size) instead of sizeof(*err) (structure size). That overestimates the bytes left for cper_arm_err_info records and can let the parser read past the CPER section when err_info_num is large enough relative to error_data_length. Use sizeof(*err) so the length accounting matches the pointer advance and the earlier sizeof(*err) size check. Fixes: 87880af2d24e ("APEI/GHES: ARM processor Error: don't go past allocated memory") Cc: stable@vger.kernel.org Signed-off-by: TanZheng Reviewed-by: Shuai Xue Link: https://patch.msgid.link/20260806010944.32384-1-kensanya@163.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: APEI: Fix ERST timeout unit conversion

2026-09-07T15:22:35+00:00

commit a685d8eea4a6899dc887e393927c16fa18ff5e9a upstream. The ACPI specification defines bits 63:32 returned by GET_EXECUTE_OPERATION_TIMINGS as the maximum execution time in microseconds. erst_get_timeout() instead multiplies the value by NSEC_PER_MSEC. Use NSEC_PER_USEC to express the firmware-provided microsecond timeout in the nanosecond units expected by erst_timedout(). Fixes: fac475aab70b ("ACPI: APEI: Use ERST timeout for slow devices") Cc: stable@vger.kernel.org Signed-off-by: Nirmoy Das Reviewed-by: Hanjun Guo Link: https://patch.msgid.link/20260721182551.2434933-1-nirmoyd@nvidia.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

acpi/apei/ghes: Use raw_spinlock_t for CXL CPER work locks

2026-09-07T15:22:35+00:00

commit 6625ca499c3131ef63be3215f8f942d7a097ea3a upstream. The CXL CPER work registration and unregistration helpers acquire cxl_cper_work_lock and cxl_cper_prot_err_work_lock with a spinlock guard(), which leaves local interrupts enabled. The corresponding post paths (cxl_cper_post_event(), cxl_cper_post_prot_err()) execute in hard IRQ context (they are called from the GHES error notification path) and acquire the same locks with an irqsave guard(). If a CPU is holding one of these locks via a spinlock guard() when a GHES interrupt arrives on the same CPU, the IRQ handler spins on the held lock waiting for it to release, while the lock holder is preempted by the IRQ. The result is a deadlock. Convert both locks from spinlock_t to raw_spinlock_t and use guard() at all call sites. On PREEMPT_RT kernels spinlock_t is backed by rt_mutex and sleeping from hard IRQ context is not permitted; raw_spinlock_t is safe in both contexts. Add WARN_ONCE to both register functions to surface double-registration bugs at runtime. Restructure both unregister functions to clear the global work pointer under the lock before calling cancel_work_sync(), closing the window where a CPER interrupt could schedule work on a pointer about to be freed. Add kfifo_reset() after cancel_work_sync() so stale entries are not replayed on next module load. Both kfifos are single-consumer: only one work_struct is registered at a time, enforced by the WARN_ONCE guard in the register functions. kfifo_reset() is safe outside the lock because cancel_work_sync() has already quiesced the consumer, and no new consumer can register until the current module exit completes and a fresh module init runs. Remove the redundant cancel_work_sync() call from cxl_ras_exit() and cxl_pci_driver_exit(). The CPER unregister functions now quiesce the work internally. Reported-by: Sashiko Signed-off-by: Terry Bowman Fixes: 5e4a264bf8b5 ("acpi/ghes: Process CXL Component Events") Fixes: 36f257e3b0ba ("acpi/ghes, cxl/pci: Process CXL CPER Protocol Errors") Cc: stable@vger.kernel.org Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Reviewed-by: Tony Luck Link: https://patch.msgid.link/20260803221810.3685703-4-terry.bowman@amd.com Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman

ACPI: NFIT: core: Fix possible deadlock and missing notifications

2026-07-24T14:17:20+00:00

[ Upstream commit 18a00ed0e718473f5c3fcfa49df46c944575e60c ] After commit 9b311b7313d6 ("ACPI: NFIT: Install Notify() handler before getting NFIT table"), ACPI NFIT driver removal may deadlock if an ACPI notify on the NFIT device is triggered concurrently. A similar deadlock may occur if an ACPI notify on the NFIT device is triggered during a failing driver probe. The deadlock is possible because acpi_dev_remove_notify_handler() calls acpi_os_wait_events_complete() after removing the notify handler and the driver core invokes it under the NFIT platform device lock which is also acquired by acpi_nfit_notify(). Thus acpi_os_wait_events_complete() may be waiting for acpi_nfit_notify() to complete, but the latter may not be able to acquire the device lock which is being held by the driver core while the former is being executed. Moreover, after commit 03667e146f81 ("ACPI: NFIT: core: Convert the driver to a platform one"), there are no sysfs notifications regarding NVDIMM devices because __acpi_nvdimm_notify() always bails out after checking the driver data pointer of the device's parent. That parent is the ACPI companion of the platform device used for driver binding, so its driver data pointer is always NULL after the commit in question which was overlooked by it. A remedy for the deadlock is to use a special separate lock for ACPI notify synchronization with driver probe and removal instead of the device lock of the NFIT device, while a remedy for the second issue is to populate the driver data pointer of the NFIT device's ACPI companion when the driver is ready to operate, so do both these things. However, since the new lock is not held across the entire teardown and acpi_nfit_notify() should do nothing when teardown is in progress, make it check the driver data pointer of the NFIT device's ACPI companion, in analogy with the existing check in __acpi_nvdimm_notify(), and bail out if that pointer is NULL. Fixes: 9b311b7313d6 ("ACPI: NFIT: Install Notify() handler before getting NFIT table") Fixes: 03667e146f81 ("ACPI: NFIT: core: Convert the driver to a platform one") Signed-off-by: Rafael J. Wysocki Cc: All applicable # 9995e4404ea4: ACPI: NFIT: core: Eliminate redundant local variable Reviewed-by: Dave Jiang Link: https://patch.msgid.link/3420096.aeNJFYEL58@rafael.j.wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman