kern/54697: ACPICA: Uninitialized variable

[max%m00nbsd.net@localhost]

>Number:         54697
>Category:       kern
>Synopsis:       ACPICA: Uninitialized variable
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 15 07:55:00 +0000 2019
>Originator:     maxv
>Release:        NetBSD-current
>Organization:
TNF
>Environment:
KMSAN amd64
>Description:
An uninitialized variable found by KMSAN in ACPICA. Note that this code is not
specific to NetBSD; maybe we should report upstream? Stack trace:

	panic: MSan: Uninitialized Malloc Memory From AcpiExGetNameString()
	AcpiUtValidNameChar()
	AcpiUtRepairName()
	AcpiNsSearchAndEnter()
	AcpiNsLookup()
	AcpiDsCreateOperand()
	[the part below is not relevant, but fwiw]
	AcpiDsCreateOperands()
	AcpiDsExecEndOp()
	AcpiPsParseLoop()
	AcpiPsParseAml()
	AcpiPsExecuteMethod()
	AcpiNsEvaluate()
	AcpiNsInitOneDevice()
	AcpiNsWalkNamespace()
	AcpiNsInitializeDevices()
	AcpiInitializeObjects()
	acpi_attach()

AcpiDsCreateOperand() calls AcpiExGetNameString() which allocates an
uninitialized buffer. This buffer is initialized by several functions called
in the stack trace.

In AcpiNsLookup(), the variable is "Pathname". You can see the first 4 bytes
are then converted to an uint32_t in acpica/dist/namespace/nsaccess.c line 648:

	ACPI_MOVE_32_TO_32 (&SimpleName, Path);

This "SimpleName" variable is then passed to AcpiNsSearchAndEnter(), and then
again to AcpiUtRepairName() in acpica/dist/namespace/nssearch.c line 329:

	AcpiUtRepairName (ACPI_CAST_PTR (char, &TargetName));

This function iterates on the four bytes, calls AcpiUtValidNameChar() on each
byte. Finally, KMSAN fires in AcpiUtValidNameChar(), because one of the bytes
is not initialized.
>How-To-Repeat:
Build KMSAN on amd64, with all the mandatory/optional parameters.
Boot, and you'll see the panic.
This is 100% reproducible.
>Fix:
Don't know.