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


Reply via email to