The ACPI_ALLOCATE() does not zero the "buf", so when the condition "integer->type != ACPI_TYPE_INTEGER" in int_to_buf() is met, the result is unpredictable in acpi_nfit_ctl().
Signed-off-by: Zhen Lei <thunder.leiz...@huawei.com> --- drivers/acpi/nfit/core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c index 442608220b5c..cda7b6c52504 100644 --- a/drivers/acpi/nfit/core.c +++ b/drivers/acpi/nfit/core.c @@ -282,18 +282,19 @@ static union acpi_object *pkg_to_buf(union acpi_object *pkg) static union acpi_object *int_to_buf(union acpi_object *integer) { - union acpi_object *buf = ACPI_ALLOCATE(sizeof(*buf) + 4); + union acpi_object *buf = NULL; void *dst = NULL; - if (!buf) - goto err; - if (integer->type != ACPI_TYPE_INTEGER) { WARN_ONCE(1, "BIOS bug, unexpected element type: %d\n", integer->type); goto err; } + buf = ACPI_ALLOCATE(sizeof(*buf) + 4); + if (!buf) + goto err; + dst = buf + 1; buf->type = ACPI_TYPE_BUFFER; buf->buffer.length = 4; -- 2.26.0.106.g9fadedd