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 <[email protected]>
---
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
On Tue, Nov 17, 2020 at 11:36 PM Zhen Lei <[email protected]> wrote:
>
> 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 <[email protected]>
Looks good to me.
Reviewed-by: Dan Williams <[email protected]>
I'll pick this up.