pcc_cpufreq_do_osc() uses a two-phase _OSC evaluation and frees the
output buffer returned by the first acpi_evaluate_object() call before
reusing the same acpi_buffer in the second call.

However, output.pointer and output.length are not reset after the
first kfree(). That can make the second acpi_evaluate_object() treat
the stale metadata as a caller-provided buffer and write into freed
memory. The shared out_free path can then free the same pointer again.

Reset the output buffer state after the first kfree() so ACPICA
allocates a fresh buffer for the second _OSC evaluation.

Fixes: 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")
Issue found using a prototype static analysis tool
and confirmed by code review.

Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Signed-off-by: Slavin Liu <220245772@seu.edu.cn>
---
 drivers/cpufreq/pcc-cpufreq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index ac2e90a65f0c..a355ec4f3dd4 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -352,6 +352,8 @@ static int __init pcc_cpufreq_do_osc(acpi_handle *handle)
 	}
 
 	kfree(output.pointer);
+	output.pointer = NULL;
+	output.length = ACPI_ALLOCATE_BUFFER;
 	capabilities[0] = 0x0;
 	capabilities[1] = 0x1;
 
-- 
2.50.1.windows.1

On 5/13/2026 8:06 PM, Hongyan Xu wrote:
> pcc_cpufreq_do_osc() uses a two-phase _OSC evaluation and frees the
> output buffer returned by the first acpi_evaluate_object() call before
> reusing the same acpi_buffer in the second call.
> 
> However, output.pointer and output.length are not reset after the
> first kfree(). That can make the second acpi_evaluate_object() treat
> the stale metadata as a caller-provided buffer and write into freed
> memory. The shared out_free path can then free the same pointer again.
> 
> Reset the output buffer state after the first kfree() so ACPICA
> allocates a fresh buffer for the second _OSC evaluation.
> 
> Fixes: 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")
> Issue found using a prototype static analysis tool
> and confirmed by code review.
> 
> Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
> Signed-off-by: Slavin Liu <220245772@seu.edu.cn>
> ---
>   drivers/cpufreq/pcc-cpufreq.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
> index ac2e90a65f0c..a355ec4f3dd4 100644
> --- a/drivers/cpufreq/pcc-cpufreq.c
> +++ b/drivers/cpufreq/pcc-cpufreq.c
> @@ -352,6 +352,8 @@ static int __init pcc_cpufreq_do_osc(acpi_handle *handle)
>   	}
>   
>   	kfree(output.pointer);
> +	output.pointer = NULL;
> +	output.length = ACPI_ALLOCATE_BUFFER;


Hi Hongyan, Slavin,

Thanks for the patch and for looking into this issue.

There is already a similar patch under discussion:
v1: https://lore.kernel.org/all/20260415165139.14113-1-dbgh9129@gmail.com/
v2: https://lore.kernel.org/all/20260416144621.93964-1-dbgh9129@gmail.com/

You may want to review that thread and see if your findings or testing
can be contributed there.


>   	capabilities[0] = 0x0;
>   	capabilities[1] = 0x1;
>   


-- 
Thx and BRs,
Zhongqiu Han