Re: [PATCH] ACPI: ADXL: verify component name types

["Luck, Tony" <tony.luck@intel.com>]

On Tue, Nov 03, 2026 at 07:41:49PM +0800, Kang Chen wrote:
> adxl_init() stores p[i].string.pointer for every component name
> without checking that the element is a string.  An integer element
> makes the pointer the integer value, which adxl_decode() consumers
> dereference with strcmp() and %s, causing a wild read during boot on
> machines with an ADXL object.
> 
> Reject the interface if any component name is not a string.

Has this ever happened on a real system? Or is this just an:

	"AI told me there was a *potential* bug" 

issue?


> 
> Fixes: 4cf841e39850 ("ACPI/ADXL: Add address translation interface using an ACPI DSM")
> Signed-off-by: Kang Chen <k.chen@smail.nju.edu.cn>
> ---
>  drivers/acpi/acpi_adxl.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/acpi_adxl.c b/drivers/acpi/acpi_adxl.c
> index 13c8f7b50c46..de646b312eba 100644
> --- a/drivers/acpi/acpi_adxl.c
> +++ b/drivers/acpi/acpi_adxl.c
> @@ -184,8 +184,17 @@ static int __init adxl_init(void)
>  		return -ENOMEM;
>  	}
>  
> -	for (i = 0; i < adxl_count; i++)
> +	for (i = 0; i < adxl_count; i++) {
> +		if (p[i].type != ACPI_TYPE_STRING) {
> +			pr_info("Bad component name type %d\n", p[i].type);

If this really happens, then Linux has a way to point a finger at the
source of the problem:

			pr_info(FW_BUG "Bad component name type %d\n", p[i].type);

> +			kfree(adxl_component_names);
> +			adxl_component_names = NULL;
> +			ACPI_FREE(params);
> +			params = NULL;
> +			return -ENODEV;
> +		}
>  		adxl_component_names[i] = p[i].string.pointer;
> +	}
>  
>  	return 0;
>  }
> -- 
> 2.34.1
> 
-Tony