ACPI: NFIT: prevent underflow in acpi_nfit_ctl()

The concern here would be that "family" is negative and we pass a negative value to test_bit() resulting in an out of bounds read and potentially a crash.

This patch is based on static analysis and not on testing.

Fixes 9a7e3d7f0568 ("ACPI: NFIT: Fix input validation of bus-family")

Signed-off-by Dan Carpenter <[email protected]>

---
v2: add missing close parens ) in subject

 drivers/acpi/nfit/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/acpi/nfit/core.c +1 -1

index f1cc5ec6a3b6..da0739f04c98 100644
@@ -446,10 +446,10 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
 	const char *cmd_name, *dimm_name;
 	unsigned long cmd_mask, dsm_mask;
 	u32 offset, fw_status = 0;
+	unsigned int family = 0;
 	acpi_handle handle;
 	const guid_t *guid;
 	int func, rc, i;
-	int family = 0;
 
 	if (cmd_rc)
 		*cmd_rc = -EINVAL;

Quoted 3 lines · Dan Carpenter

The concern here would be that "family" is negative and we pass a negative value to test_bit() resulting in an out of bounds read and potentially a crash.

I don't see how this can happen. Do you have a particular scenario in mind?

Quoted 9 lines · Jeff Moyer

Quoted 3 lines · Dan Carpenter

The concern here would be that "family" is negative and we pass a negative value to test_bit() resulting in an out of bounds read and potentially a crash.

I don't see how this can happen. Do you have a particular scenario in mind?

This is from static analysis. My main thinking was:

1) The static checker says that this comes from the user.
2) Every upper bounds check should have a lower bounds check.
3) family is passed to array_index_nospec() so we must not trust it.

But looking closer today here is what the checker is concerned about:

	func = cmd_to_func(nfit_mem, cmd, call_pkg, &family);

Assume "nfit_mem" is NULL but "call_pkg" is non NULL (user input from __nd_ioctl() or ars_get_status(). In that case family is unchecked user input.

But probably, it's not possible for nfit_mem to be NULL in those caller functions?

Quoted 21 lines · Dan Carpenter

Quoted 9 lines · Jeff Moyer

Quoted 3 lines · Dan Carpenter

The concern here would be that "family" is negative and we pass a negative value to test_bit() resulting in an out of bounds read and potentially a crash.

I don't see how this can happen. Do you have a particular scenario in mind?

This is from static analysis. My main thinking was:

1) The static checker says that this comes from the user.
2) Every upper bounds check should have a lower bounds check.
3) family is passed to array_index_nospec() so we must not trust it.

But looking closer today here is what the checker is concerned about:

	func = cmd_to_func(nfit_mem, cmd, call_pkg, &family);

Quoted 6 lines

Assume "nfit_mem" is NULL but "call_pkg" is non NULL (user input from __nd_ioctl() or ars_get_status(). In that case family is unchecked user input.

But probably, it's not possible for nfit_mem to be NULL in those caller functions?

Did we ever figure out if it's possible for nfit_mem to be NULL?