linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] watchdog: dw_wdt: Fix buffer overflow when get timeout
@ 2022-06-28  5:45 Schspa Shi
  2022-06-28 13:55 ` Guenter Roeck
  0 siblings, 1 reply; 3+ messages in thread
From: Schspa Shi @ 2022-06-28  5:45 UTC (permalink / raw)
  To: wim, linux; +Cc: linux-watchdog, linux-kernel, zhaohui.shi, Schspa Shi

The top_val can be obtained from device-tree, if it is not configured
correctly, there will be buffer overflow.

Signed-off-by: Schspa Shi <schspa@gmail.com>
---
 drivers/watchdog/dw_wdt.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index cd578843277e..1f8605c0d712 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -155,6 +155,9 @@ static unsigned int dw_wdt_get_min_timeout(struct dw_wdt *dw_wdt)
 			break;
 	}
 
+	if (WARN_ON_ONCE(idx == DW_WDT_NUM_TOPS))
+		idx = DW_WDT_NUM_TOPS - 1;
+
 	return dw_wdt->timeouts[idx].sec;
 }
 
@@ -178,6 +181,9 @@ static unsigned int dw_wdt_get_timeout(struct dw_wdt *dw_wdt)
 			break;
 	}
 
+	if (WARN_ON_ONCE(idx == DW_WDT_NUM_TOPS))
+		idx = DW_WDT_NUM_TOPS - 1;
+
 	/*
 	 * In IRQ mode due to the two stages counter, the actual timeout is
 	 * twice greater than the TOP setting.
-- 
2.29.0


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] watchdog: dw_wdt: Fix buffer overflow when get timeout
  2022-06-28  5:45 [PATCH] watchdog: dw_wdt: Fix buffer overflow when get timeout Schspa Shi
@ 2022-06-28 13:55 ` Guenter Roeck
  2022-06-28 14:30   ` Schspa Shi
  0 siblings, 1 reply; 3+ messages in thread
From: Guenter Roeck @ 2022-06-28 13:55 UTC (permalink / raw)
  To: Schspa Shi, wim; +Cc: linux-watchdog, linux-kernel, zhaohui.shi

On 6/27/22 22:45, Schspa Shi wrote:
> The top_val can be obtained from device-tree, if it is not configured
> correctly, there will be buffer overflow.
> 
> Signed-off-by: Schspa Shi <schspa@gmail.com>
> ---
>   drivers/watchdog/dw_wdt.c | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
> index cd578843277e..1f8605c0d712 100644
> --- a/drivers/watchdog/dw_wdt.c
> +++ b/drivers/watchdog/dw_wdt.c
> @@ -155,6 +155,9 @@ static unsigned int dw_wdt_get_min_timeout(struct dw_wdt *dw_wdt)
>   			break;
>   	}
>   
> +	if (WARN_ON_ONCE(idx == DW_WDT_NUM_TOPS))
> +		idx = DW_WDT_NUM_TOPS - 1;
> +
dw_wdt_get_min_timeout() returns the lowest non-0 configurable timeout.
The  last entry in the timeout array must not be 0, meaning there must
be at least one entry in the array where the timeout is not 0. Therefore
this situation can not happen.

>   	return dw_wdt->timeouts[idx].sec;
>   }
>   
> @@ -178,6 +181,9 @@ static unsigned int dw_wdt_get_timeout(struct dw_wdt *dw_wdt)
>   			break;
>   	}
>   
> +	if (WARN_ON_ONCE(idx == DW_WDT_NUM_TOPS))
> +		idx = DW_WDT_NUM_TOPS - 1;
> +

idx is derived from a top_val value written into WDOG_TIMEOUT_RANGE_REG_OFFSET,
and the value written is derived from an entry in the timeouts array.
This array contains an entry for each possible top_val. While the array is not
sorted by top_val, dw_wdt_handle_tops() still guarantees that an entry exists.

I do not see how bad devicetree data can circumvent that. If it does, please
provide an example and explain.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] watchdog: dw_wdt: Fix buffer overflow when get timeout
  2022-06-28 13:55 ` Guenter Roeck
@ 2022-06-28 14:30   ` Schspa Shi
  0 siblings, 0 replies; 3+ messages in thread
From: Schspa Shi @ 2022-06-28 14:30 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: wim, linux-watchdog, Linux Kernel Mailing List

Guenter Roeck <linux@roeck-us.net> writes:

> On 6/27/22 22:45, Schspa Shi wrote:
>> The top_val can be obtained from device-tree, if it is not configured
>> correctly, there will be buffer overflow.
>> Signed-off-by: Schspa Shi <schspa@gmail.com>
>> ---
>>   drivers/watchdog/dw_wdt.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>> diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
>> index cd578843277e..1f8605c0d712 100644
>> --- a/drivers/watchdog/dw_wdt.c
>> +++ b/drivers/watchdog/dw_wdt.c
>> @@ -155,6 +155,9 @@ static unsigned int dw_wdt_get_min_timeout(struct dw_wdt *dw_wdt)
>>                      break;
>>      }
>>   +  if (WARN_ON_ONCE(idx == DW_WDT_NUM_TOPS))
>> +            idx = DW_WDT_NUM_TOPS - 1;
>> +
> dw_wdt_get_min_timeout() returns the lowest non-0 configurable timeout.
> The  last entry in the timeout array must not be 0, meaning there must
> be at least one entry in the array where the timeout is not 0. Therefore
> this situation can not happen.
>

Yes, I have seen this, you are correct, sorry for the bad patch.

>>      return dw_wdt->timeouts[idx].sec;
>>   }
>>   @@ -178,6 +181,9 @@ static unsigned int dw_wdt_get_timeout(struct dw_wdt
>> *dw_wdt)
>>                      break;
>>      }
>>   +  if (WARN_ON_ONCE(idx == DW_WDT_NUM_TOPS))
>> +            idx = DW_WDT_NUM_TOPS - 1;
>> +
>
> idx is derived from a top_val value written into WDOG_TIMEOUT_RANGE_REG_OFFSET,
> and the value written is derived from an entry in the timeouts array.
> This array contains an entry for each possible top_val. While the array is not
> sorted by top_val, dw_wdt_handle_tops() still guarantees that an entry exists.
>
> I do not see how bad devicetree data can circumvent that. If it does, please
> provide an example and explain.
>

My bad, there is no problem.

> Thanks,
> Guenter


-- 
BRs
Schspa Shi

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-06-28 14:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-28  5:45 [PATCH] watchdog: dw_wdt: Fix buffer overflow when get timeout Schspa Shi
2022-06-28 13:55 ` Guenter Roeck
2022-06-28 14:30   ` Schspa Shi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).