From d776369a9eded071df83e4738e1572c4c5b912d7 Mon Sep 17 00:00:00 2001 From: Karl Mehltretter Date: Thu, 27 Aug 2026 07:37:41 +0200 Subject: [PATCH 1/7] ACPI: pfr_update: zero-initialize capability query result query_capability() copies four ACPI buffers into fixed-size fields using the firmware-supplied lengths. The existing overflow guard rejects oversized buffers, but shorter buffers are accepted and leave trailing bytes of the stack-allocated cap_hdr uninitialized. PFRU_IOC_QUERY_CAP then copies the entire structure to userspace. Zero-initialize cap_hdr before querying the firmware. This preserves the existing handling of short firmware responses while preventing disclosure of kernel stack data. Oversized buffers remain rejected. A QEMU _DSM returning one-byte buffers reproduced nonzero stack suffix bytes in all four fields. With this change, the ioctl still succeeds and each unwritten suffix is zero-filled, while 64-byte buffers continue to return -EINVAL. Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/1a001e1fee9.637da6dc3533246.238498880682901704%40a0rg.com Cc: All applicable Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260827053741.79425-1-kmehltretter@gmail.com Signed-off-by: Rafael J. Wysocki --- drivers/acpi/pfr_update.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/pfr_update.c b/drivers/acpi/pfr_update.c index 9afd2c52fdbd..98ace679601b 100644 --- a/drivers/acpi/pfr_update.c +++ b/drivers/acpi/pfr_update.c @@ -422,7 +422,7 @@ static int start_update(int action, struct pfru_device *pfru_dev) static long pfru_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { - struct pfru_update_cap_info cap_hdr; + struct pfru_update_cap_info cap_hdr = {}; struct pfru_device *pfru_dev = to_pfru_dev(file); void __user *p = (void __user *)arg; u32 rev; From d54229a6b6d68296a4d9c5067c3bc061da639a66 Mon Sep 17 00:00:00 2001 From: Myeonghun Pak Date: Thu, 10 Sep 2026 16:37:27 -0400 Subject: [PATCH 2/7] PNP: Detach device after resource transition failure pnp_device_probe() attaches the PNP device before it activates or disables its resources. The attach changes the status from PNP_READY to PNP_ATTACHED, but errors from either resource transition return directly and leave that status behind. A later bind or manual PNP configuration attempt then sees a device that is still marked in use. Route both errors through the existing failure path so it restores the status to PNP_READY. Do not disable the device or clean its resources: pnp_activate_dev() only marks it active after a successful start, while pnp_disable_dev() preserves the active state and resource table when stopping fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260910203727.63489-1-mhun512@gmail.com Signed-off-by: Rafael J. Wysocki --- drivers/pnp/driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c index 6d58b1465081..80c2a0f15b80 100644 --- a/drivers/pnp/driver.c +++ b/drivers/pnp/driver.c @@ -96,13 +96,13 @@ static int pnp_device_probe(struct device *dev) if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) { error = pnp_activate_dev(pnp_dev); if (error < 0) - return error; + goto fail; } } else if ((pnp_drv->flags & PNP_DRIVER_RES_DISABLE) == PNP_DRIVER_RES_DISABLE) { error = pnp_disable_dev(pnp_dev); if (error < 0) - return error; + goto fail; } error = 0; if (pnp_drv->probe) { From b9026ef6189ef44b32b4163431c8666be3cbd881 Mon Sep 17 00:00:00 2001 From: Lalit Shankar Chowdhury Date: Mon, 21 Sep 2026 08:14:11 +0000 Subject: [PATCH 3/7] ACPI: WMI: use IS_ENABLED() to simplify built-in or module check Replace the remaining built-in/module check for CONFIG_ACPI_WMI with IS_ENABLED() macro. Signed-off-by: Lalit Shankar Chowdhury Reviewed-by: Armin Wolf [ rjw: Subject tweaks ] Link: https://patch.msgid.link/20260921081411.4819-1-lalitshankarch@gmail.com Signed-off-by: Rafael J. Wysocki --- include/linux/acpi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index ddacac812094..b590f520dc57 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -434,7 +434,7 @@ extern acpi_handle ec_get_handle(void); extern bool acpi_is_pnp_device(struct acpi_device *); -#if defined(CONFIG_ACPI_WMI) || defined(CONFIG_ACPI_WMI_MODULE) +#if IS_ENABLED(CONFIG_ACPI_WMI) typedef void (*wmi_notify_handler) (union acpi_object *data, void *context); From 46c263c213876bdc2297ef61aa90f0b210ebac73 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Tue, 22 Sep 2026 15:43:00 +0100 Subject: [PATCH 4/7] ACPI: PCC: Preserve shared memory signature in OpRegion handler ACPI 6.3 introduced PCC OperationRegions. Section 5.5.2.4.7.3, "Declaring message fields within a PCC OperationRegion", states that, for all PCC subspace types, the PCC Operation Region pertains to the region of PCC subspace that succeeds the PCC signature. Its length therefore excludes the 4-byte signature. The PCC address space handler currently copies the OperationRegion buffer to and from the start of the shared memory. This overwrites or exposes the platform-populated signature and omits the final four bytes of the OperationRegion. Offset the copies by the size of the signature and reject an OperationRegion that does not fit in the remaining shared memory. The example added by commit 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype") incorrectly included the signature as an OperationRegion field. A Type 3 OperationRegion containing a 100-byte communication area is declared as follows: OperationRegion (PFRM, PCC, 2, 0x70) Field (PFRM, ByteAcc, NoLock, Preserve) { FLGS, 32, LEN, 32, CMD, 32, DATA, 800 } This contains three 32-bit fields followed by a 100-byte DATA field. The fields correspond to the Type 3 shared memory layout in ACPI 6.3, Table 14-372, after excluding its 4-byte signature. Fixes: 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype") Reviewed-by: Huisong Li Signed-off-by: Sudeep Holla Link: https://patch.msgid.link/20260922144302.3847593-3-sudeep.holla@kernel.org Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_pcc.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c index 438c67189511..9881c9ee293d 100644 --- a/drivers/acpi/acpi_pcc.c +++ b/drivers/acpi/acpi_pcc.c @@ -28,6 +28,7 @@ * to PCC commands */ #define PCC_CMD_WAIT_RETRIES_NUM 500ULL +#define PCC_SIGNATURE_SIZE sizeof(u32) struct pcc_data { struct pcc_mbox_chan *pcc_chan; @@ -74,6 +75,14 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function, } pcc_chan = data->pcc_chan; + if (pcc_chan->shmem_size < PCC_SIGNATURE_SIZE || + ctx->length > pcc_chan->shmem_size - PCC_SIGNATURE_SIZE) { + pr_err("PCC channel-%d shared memory is too small.\n", + ctx->subspace_id); + ret = AE_AML_REGION_LIMIT; + goto err_free_channel; + } + if (!pcc_chan->mchan->mbox->txdone_irq) { pr_err("This channel-%d does not support interrupt.\n", ctx->subspace_id); @@ -97,14 +106,17 @@ acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr, u32 bits, acpi_integer *value, void *handler_context, void *region_context) { - int ret; struct pcc_data *data = region_context; + void __iomem *pcc_opregion; u64 usecs_lat; + int ret; + + pcc_opregion = data->pcc_chan->shmem + PCC_SIGNATURE_SIZE; reinit_completion(&data->done); - /* Write to Shared Memory */ - memcpy_toio(data->pcc_chan->shmem, (void *)value, data->ctx.length); + /* Write to the PCC OperationRegion after the shared memory signature. */ + memcpy_toio(pcc_opregion, (void *)value, data->ctx.length); ret = mbox_send_message(data->pcc_chan->mchan, NULL); if (ret < 0) @@ -125,7 +137,7 @@ acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr, mbox_chan_txdone(data->pcc_chan->mchan, ret); - memcpy_fromio(value, data->pcc_chan->shmem, data->ctx.length); + memcpy_fromio(value, pcc_opregion, data->ctx.length); return AE_OK; } From fa9c7ee692988edddc1da74bc5257d53dd3c7130 Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Tue, 22 Sep 2026 15:43:01 +0100 Subject: [PATCH 5/7] ACPI: PCC: Free channel on OpRegion deactivation ACPICA calls the address space setup callback with ACPI_REGION_DEACTIVATE when a PCC OperationRegion is torn down. The PCC setup callback currently allocates a fresh pcc_data and requests the mailbox channel before looking at the function argument. If ACPICA deactivates a region, this can leave the existing region context and mailbox channel unreleased, and may also request a channel during teardown. Handle ACPI_REGION_DEACTIVATE before allocation. Free the PCC mailbox channel, release the region context and clear the context pointer. Fixes: 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype") Reviewed-by: Huisong Li Signed-off-by: Sudeep Holla Link: https://patch.msgid.link/20260922144302.3847593-4-sudeep.holla@kernel.org Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_pcc.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c index 9881c9ee293d..57d13b25c1d6 100644 --- a/drivers/acpi/acpi_pcc.c +++ b/drivers/acpi/acpi_pcc.c @@ -55,6 +55,19 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function, struct pcc_mbox_chan *pcc_chan; acpi_status ret; + if (function == ACPI_REGION_DEACTIVATE) { + data = *region_context; + if (data) { + pcc_mbox_free_channel(data->pcc_chan); + kfree(data); + *region_context = NULL; + } + return AE_OK; + } + + if (function != ACPI_REGION_ACTIVATE) + return AE_BAD_PARAMETER; + data = kzalloc_obj(*data); if (!data) return AE_NO_MEMORY; From c0232f00f703a409bb6e6080d94f6dc7fdebe5ca Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Tue, 22 Sep 2026 15:43:02 +0100 Subject: [PATCH 6/7] ACPI: PCC: Cache OpRegion command timeout The PCC OperationRegion handler computes the same command completion wait timeout each time it sends a command. The timeout is derived from static channel properties, so compute it once when the PCC channel is set up and store the millisecond value in the mailbox client timeout field. Use the cached timeout when waiting for the OperationRegion command to complete. This keeps the timeout calculation in one place and avoids recomputing it for every command. Reviewed-by: Huisong Li Signed-off-by: Sudeep Holla Link: https://patch.msgid.link/20260922144302.3847593-5-sudeep.holla@kernel.org Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_pcc.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c index 57d13b25c1d6..345f233d77cd 100644 --- a/drivers/acpi/acpi_pcc.c +++ b/drivers/acpi/acpi_pcc.c @@ -50,10 +50,11 @@ static acpi_status acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function, void *handler_context, void **region_context) { - struct pcc_data *data; struct acpi_pcc_info *ctx = handler_context; struct pcc_mbox_chan *pcc_chan; + struct pcc_data *data; acpi_status ret; + u64 usecs_lat; if (function == ACPI_REGION_DEACTIVATE) { data = *region_context; @@ -103,6 +104,16 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function, goto err_free_channel; } + /* + * pcc_chan->latency is just a Nominal value. In reality the remote + * processor could be much slower to reply. So add an arbitrary + * amount of wait on top of Nominal. + */ + usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * pcc_chan->latency; + data->cl.tx_tout = DIV_ROUND_UP_ULL(usecs_lat, 1000); + if (!data->cl.tx_tout) + data->cl.tx_tout = 1; + *region_context = data; return AE_OK; @@ -121,7 +132,6 @@ acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr, { struct pcc_data *data = region_context; void __iomem *pcc_opregion; - u64 usecs_lat; int ret; pcc_opregion = data->pcc_chan->shmem + PCC_SIGNATURE_SIZE; @@ -135,14 +145,8 @@ acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr, if (ret < 0) return AE_ERROR; - /* - * pcc_chan->latency is just a Nominal value. In reality the remote - * processor could be much slower to reply. So add an arbitrary - * amount of wait on top of Nominal. - */ - usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * data->pcc_chan->latency; ret = wait_for_completion_timeout(&data->done, - usecs_to_jiffies(usecs_lat)); + msecs_to_jiffies(data->cl.tx_tout)); if (ret == 0) { pr_err("PCC command executed timeout!\n"); return AE_TIME; From c237f6b429b914905bb379de4089d661fb370446 Mon Sep 17 00:00:00 2001 From: Hemanth Selam Date: Mon, 7 Sep 2026 12:17:25 +0530 Subject: [PATCH 7/7] ACPI: NUMA: fix typo in log message Correct the misspelling in a message the user sees, reported by scripts/checkpatch.pl using the list in scripts/spelling.txt. Only the message text changes, no code changes. Signed-off-by: Hemanth Selam Reviewed-by: Randy Dunlap Link: https://patch.msgid.link/20260907064725.10686-6-hemanth.selam@gmail.com Signed-off-by: Rafael J. Wysocki --- drivers/acpi/numa/srat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c index 5c407dc6401e..f5616830f5a9 100644 --- a/drivers/acpi/numa/srat.c +++ b/drivers/acpi/numa/srat.c @@ -111,7 +111,7 @@ int __init fix_pxm_node_maps(int max_nid) for (j = 0; j <= max_nid; j++) { if ((emu_nid_to_phys[j] == i) && WARN(node_to_pxm_map_copy[j] != PXM_INVAL, - "Node %d is already binded to PXM %d\n", + "Node %d is already bound to PXM %d\n", j, node_to_pxm_map_copy[j])) return -1; if (emu_nid_to_phys[j] == i) {