acpi: nfit: fix narrowing conversion in acpi_nfit_ctl

Commit Message

Murad Masimov Jan. 23, 2025, 4:39 p.m. UTC

Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary
bus families can be translated". This warning is emited if the argument
is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first
verifies that a user-provided value call_pkg->nd_family of type u64 is
not equal to 0. Then the value is converted to int, and only after that
is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid
argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while
the lower 32 bits are zero.

All checks of the input value should be applied to the original variable
call_pkg->nd_family.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Fixes: 6450ddbd5d8e ("ACPI: NFIT: Define runtime firmware activation commands")
Cc: [e-mail]
Reported-by: [e-mail]
Closes: https://syzkaller.appspot.com/bug?extid=c80d8dc0d9fa81a3cd8c
Signed-off-by: Murad Masimov <[e-mail]>
---
 drivers/acpi/nfit/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--
2.39.2

Comments

Dave Jiang Jan. 23, 2025, 11:43 p.m. UTC | #1

On 1/23/25 9:39 AM, Murad Masimov wrote:
> Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary
> bus families can be translated". This warning is emited if the argument
> is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first
> verifies that a user-provided value call_pkg->nd_family of type u64 is
> not equal to 0. Then the value is converted to int, and only after that
> is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid
> argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while
> the lower 32 bits are zero.
> 
> All checks of the input value should be applied to the original variable
> call_pkg->nd_family.
> 
> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
> 
> Fixes: 6450ddbd5d8e ("ACPI: NFIT: Define runtime firmware activation commands")
> Cc: [e-mail]
> Reported-by: [e-mail]
> Closes: https://syzkaller.appspot.com/bug?extid=c80d8dc0d9fa81a3cd8c
> Signed-off-by: Murad Masimov <[e-mail]>

While the change logically makes sense, the likelihood of nd_family > int_size is not ever likely. Given that NVDIMM_BUS_FAMILY_MAX is defined as 1, I don't think we care about values greater than that regardless of what is set in the upper 32bit of the u64. I'm leaning towards the fix is unnecessary.   

> ---
>  drivers/acpi/nfit/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index a5d47819b3a4..ae035b93da08 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -485,7 +485,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
>  		cmd_mask = nd_desc->cmd_mask;
>  		if (cmd == ND_CMD_CALL && call_pkg->nd_family) {
>  			family = call_pkg->nd_family;
> -			if (family > NVDIMM_BUS_FAMILY_MAX ||
> +			if (call_pkg->nd_family > NVDIMM_BUS_FAMILY_MAX ||
>  			    !test_bit(family, &nd_desc->bus_family_mask))
>  				return -EINVAL;
>  			family = array_index_nospec(family,
> --
> 2.39.2
>

Alison Schofield Jan. 24, 2025, 4:58 p.m. UTC | #2

On Fri, Jan 24, 2025 at 02:17:51PM +0000, Murad Masimov  wrote:
> 
> ________________________________________
> От: Dave Jiang <[e-mail]>
> Отправлено: 24 января 2025 г. 2:43
> Кому: Masimov Murad; Dan Williams
> Копия: Vishal Verma; Ira Weiny; Rafael J. Wysocki; Len Brown; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Тема: Re: [PATCH] acpi: nfit: fix narrowing conversion in acpi_nfit_ctl
> 
> > On 1/23/25 9:39 AM, Murad Masimov wrote:
> > > Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary
> > > bus families can be translated". This warning is emited if the argument
> > > is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first
> > > verifies that a user-provided value call_pkg->nd_family of type u64 is
> > > not equal to 0. Then the value is converted to int, and only after that
> > > is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid
> > > argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while
> > > the lower 32 bits are zero.
> > >
> > > All checks of the input value should be applied to the original variable
> > > call_pkg->nd_family.
> > >
> > > Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
> > >
> > > Fixes: 6450ddbd5d8e ("ACPI: NFIT: Define runtime firmware activation commands")
> > > Cc: [e-mail]
> > > Reported-by: [e-mail]
> > > Closes: https://syzkaller.appspot.com/bug?extid=c80d8dc0d9fa81a3cd8c
> > > Signed-off-by: Murad Masimov <[e-mail]>
> > 
> > While the change logically makes sense, the likelihood of nd_family > int_size is not ever likely. Given that NVDIMM_BUS_FAMILY_MAX is defined as 1, I don't think we care about values greater than that regardless of what is set in the upper 32bit of the u64. I'm leaning towards the fix is unnecessary.
> 
> Thank you for the review! But I believe there is a misunderstanding. The point is that the code fragment affected by this patch is intended to make sure, that family is in range between 1 and NVDIMM_BUS_FAMILY_MAX. This is necessary because call_pkg contains user-provided data. However the implementation of these validity checks is erroneous and leads to passing an invalid value. The syzkaller report proves, that this bug can be triggered by a user. Here is an example to demonstrate, what exactly happens:
 > 
> 1. Let's say call_pkg->nd_family is equal to (1ull << 32).
> 2. Expression (cmd == ND_CMD_CALL && call_pkg->nd_family) evaluates to true.
> 3. Since family is of type int, and call_pkg->nd_family is u64, assigning call_pkg->nd_family to family will lead to a narrowing conversion.
> 4. As a result, family equals to 0, which will be passed in to_nfit_bus_uuid() triggering the warning.
> 
> Moreover, family may also be a negative integer (e.g. call_pkg->nd_family == ~(0ull)). This can lead to an undefined behaviour in test_bit() and potentially out-of-bounds in to_nfit_uuid(). Thus, even if triggering a WARN is not concerning, the bug still should be fixed.


Hi Murad,

Here's some general feedback for any Fix with a Fixes tag: the commit log
needs to state the user visible impact. State what user action fails and
include the actual error message that the user will see. That makes it
possible for folks to search and discover if a patch fixes their problem.

You've done some detailed sleuthing here but it's not clear that a
user would recognize this issue if they hit it.

--Alison


snip
>

Ira Weiny Jan. 24, 2025, 6:53 p.m. UTC | #3

Murad Masimov wrote:
> 
> ________________________________________
> От: Dave Jiang <[e-mail]>
> Отправлено: 24 января 2025 г. 2:43
> Кому: Masimov Murad; Dan Williams
> Копия: Vishal Verma; Ira Weiny; Rafael J. Wysocki; Len Brown; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Тема: Re: [PATCH] acpi: nfit: fix narrowing conversion in acpi_nfit_ctl
> 
> > On 1/23/25 9:39 AM, Murad Masimov wrote:
> > > Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary
> > > bus families can be translated". This warning is emited if the argument
> > > is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first
> > > verifies that a user-provided value call_pkg->nd_family of type u64 is
> > > not equal to 0. Then the value is converted to int, and only after that
> > > is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid
> > > argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while
> > > the lower 32 bits are zero.
> > >
> > > All checks of the input value should be applied to the original variable
> > > call_pkg->nd_family.
> > >
> > > Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
> > >
> > > Fixes: 6450ddbd5d8e ("ACPI: NFIT: Define runtime firmware activation commands")
> > > Cc: [e-mail]
> > > Reported-by: [e-mail]
> > > Closes: https://syzkaller.appspot.com/bug?extid=c80d8dc0d9fa81a3cd8c
> > > Signed-off-by: Murad Masimov <[e-mail]>
> > 
> > While the change logically makes sense, the likelihood of nd_family > int_size is not ever likely. Given that NVDIMM_BUS_FAMILY_MAX is defined as 1, I don't think we care about values greater than that regardless of what is set in the upper 32bit of the u64. I'm leaning towards the fix is unnecessary.
> 
> Thank you for the review! But I believe there is a misunderstanding. The
> point is that the code fragment affected by this patch is intended to
> make sure, that family is in range between 1 and NVDIMM_BUS_FAMILY_MAX.
> This is necessary because call_pkg contains user-provided data. However
> the implementation of these validity checks is erroneous and leads to
> passing an invalid value. The syzkaller report proves, that this bug can
> be triggered by a user. Here is an example to demonstrate, what exactly
> happens:
> 

I tend to agree this is not ideal.  But IMO the issue is that family is
treated as an int throughout the code rather than u64.  Even u32 would
have been better than int because negative numbers are not allowed AFAICT
just skimming the code.

Unfortunately, ripping through the code to change family to u32 is
probably not worth the churn.  I'll think on this but I'm tempted to apply
this.

Ira

> 1. Let's say call_pkg->nd_family is equal to (1ull << 32).
> 2. Expression (cmd == ND_CMD_CALL && call_pkg->nd_family) evaluates to true.
> 3. Since family is of type int, and call_pkg->nd_family is u64, assigning call_pkg->nd_family to family will lead to a narrowing conversion.
> 4. As a result, family equals to 0, which will be passed in to_nfit_bus_uuid() triggering the warning.
> 
> Moreover, family may also be a negative integer (e.g. call_pkg->nd_family == ~(0ull)). This can lead to an undefined behaviour in test_bit() and potentially out-of-bounds in to_nfit_uuid(). Thus, even if triggering a WARN is not concerning, the bug still should be fixed.
> 
> > > ---
> > >  drivers/acpi/nfit/core.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> > > index a5d47819b3a4..ae035b93da08 100644
> > > --- a/drivers/acpi/nfit/core.c
> > > +++ b/drivers/acpi/nfit/core.c
> > > @@ -485,7 +485,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
> > >               cmd_mask = nd_desc->cmd_mask;
> > >               if (cmd == ND_CMD_CALL && call_pkg->nd_family) {
> > >                       family = call_pkg->nd_family;
> > > -                     if (family > NVDIMM_BUS_FAMILY_MAX ||
> > > +                     if (call_pkg->nd_family > NVDIMM_BUS_FAMILY_MAX ||
> > >                           !test_bit(family, &nd_desc->bus_family_mask))
> > >                               return -EINVAL;
> > >                       family = array_index_nospec(family,
> > > --
> > > 2.39.2
> > >
>

Murad Masimov Jan. 27, 2025, 6:37 p.m. UTC | #4

> I tend to agree this is not ideal.  But IMO the issue is that family is
> treated as an int throughout the code rather than u64.  Even u32 would
> have been better than int because negative numbers are not allowed AFAICT
> just skimming the code.
> 
> Unfortunately, ripping through the code to change family to u32 is
> probably not worth the churn.  I'll think on this but I'm tempted to apply
> this.
> 
> Ira

Hi,

I believe this patch is better suited for the stable branches.
Additionally, replacing int to u32 or u64 in all relevant parts of the
code seems too risky, as it could potentially introduce new bugs.

Given the discussion so far, would it be appropriate to resend the same
patch, but with a more detailed commit message this time?

Thank you

Patch

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index a5d47819b3a4..ae035b93da08 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -485,7 +485,7 @@  int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
 		cmd_mask = nd_desc->cmd_mask;
 		if (cmd == ND_CMD_CALL && call_pkg->nd_family) {
 			family = call_pkg->nd_family;
-			if (family > NVDIMM_BUS_FAMILY_MAX ||
+			if (call_pkg->nd_family > NVDIMM_BUS_FAMILY_MAX ||
 			    !test_bit(family, &nd_desc->bus_family_mask))
 				return -EINVAL;
 			family = array_index_nospec(family,