mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] srcu: The value may overflow
@ 2023-09-01  9:53 Denis Arefev
  2023-09-01 13:31 ` Mathieu Desnoyers
  0 siblings, 1 reply; 3+ messages in thread
From: Denis Arefev @ 2023-09-01  9:53 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Paul E. McKenney, Josh Triplett, Steven Rostedt,
	Mathieu Desnoyers, rcu, lvc-project, linux-kernel, trufanov, vfh

The value of an arithmetic expression 1 << (cpu - sdp->mynode->grplo)
is subject to overflow due to a failure to cast operands to a larger
data type before performing arithmetic

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

Signed-off-by: Denis Arefev <arefev@swemel.ru>
---
 kernel/rcu/srcutree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 20d7a238d675..e14b74fb1ba0 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -223,7 +223,7 @@ static bool init_srcu_struct_nodes(struct srcu_struct *ssp, gfp_t gfp_flags)
 				snp->grplo = cpu;
 			snp->grphi = cpu;
 		}
-		sdp->grpmask = 1 << (cpu - sdp->mynode->grplo);
+		sdp->grpmask = 1UL << (cpu - sdp->mynode->grplo);
 	}
 	smp_store_release(&ssp->srcu_sup->srcu_size_state, SRCU_SIZE_WAIT_BARRIER);
 	return true;
-- 
2.25.1


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

* Re: [PATCH] srcu: The value may overflow
  2023-09-01  9:53 [PATCH] srcu: The value may overflow Denis Arefev
@ 2023-09-01 13:31 ` Mathieu Desnoyers
  2023-09-02 14:17   ` Mathieu Desnoyers
  0 siblings, 1 reply; 3+ messages in thread
From: Mathieu Desnoyers @ 2023-09-01 13:31 UTC (permalink / raw)
  To: Denis Arefev, Lai Jiangshan
  Cc: Paul E. McKenney, Josh Triplett, Steven Rostedt, rcu,
	lvc-project, linux-kernel, trufanov, vfh

On 9/1/23 05:53, Denis Arefev wrote:
> The value of an arithmetic expression 1 << (cpu - sdp->mynode->grplo)
> is subject to overflow due to a failure to cast operands to a larger
> data type before performing arithmetic
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Signed-off-by: Denis Arefev <arefev@swemel.ru>
> ---
>   kernel/rcu/srcutree.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index 20d7a238d675..e14b74fb1ba0 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -223,7 +223,7 @@ static bool init_srcu_struct_nodes(struct srcu_struct *ssp, gfp_t gfp_flags)
>   				snp->grplo = cpu;
>   			snp->grphi = cpu;
>   		}
> -		sdp->grpmask = 1 << (cpu - sdp->mynode->grplo);
> +		sdp->grpmask = 1UL << (cpu - sdp->mynode->grplo);

What possible values of cpus supported by the Linux kernel and grplo can 
cause this to overflow on 64-bit architectures ? I suspect the maximum 
result of this subtraction is defined by the RCU_FANOUT or other srcu 
level-spread values assigned by rcu_init_levelspread(), which can indeed 
cause the signed 32-bit integer literal ("1") to overflow when shifted 
by any value greater than 31. This analysis should be added to the 
commit message so the impact of the issue can be understood.

I also notice this in the same file:

srcu_schedule_cbs_snp():

         for (cpu = snp->grplo; cpu <= snp->grphi; cpu++) {
                 if (!(mask & (1 << (cpu - snp->grplo))))
                         continue;

Which should be fixed at the same time.

Thanks,

Mathieu

>   	}
>   	smp_store_release(&ssp->srcu_sup->srcu_size_state, SRCU_SIZE_WAIT_BARRIER);
>   	return true;

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com


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

* Re: [PATCH] srcu: The value may overflow
  2023-09-01 13:31 ` Mathieu Desnoyers
@ 2023-09-02 14:17   ` Mathieu Desnoyers
  0 siblings, 0 replies; 3+ messages in thread
From: Mathieu Desnoyers @ 2023-09-02 14:17 UTC (permalink / raw)
  To: Denis Arefev, Lai Jiangshan, Paul E. McKenney
  Cc: Josh Triplett, Steven Rostedt, rcu, lvc-project, linux-kernel,
	trufanov, vfh

On 9/1/23 09:31, Mathieu Desnoyers wrote:
> On 9/1/23 05:53, Denis Arefev wrote:
>> The value of an arithmetic expression 1 << (cpu - sdp->mynode->grplo)
>> is subject to overflow due to a failure to cast operands to a larger
>> data type before performing arithmetic
>>
>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>
>> Signed-off-by: Denis Arefev <arefev@swemel.ru>
>> ---
>>   kernel/rcu/srcutree.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
>> index 20d7a238d675..e14b74fb1ba0 100644
>> --- a/kernel/rcu/srcutree.c
>> +++ b/kernel/rcu/srcutree.c
>> @@ -223,7 +223,7 @@ static bool init_srcu_struct_nodes(struct 
>> srcu_struct *ssp, gfp_t gfp_flags)
>>                   snp->grplo = cpu;
>>               snp->grphi = cpu;
>>           }
>> -        sdp->grpmask = 1 << (cpu - sdp->mynode->grplo);
>> +        sdp->grpmask = 1UL << (cpu - sdp->mynode->grplo);
> 
> What possible values of cpus supported by the Linux kernel and grplo can 
> cause this to overflow on 64-bit architectures ? I suspect the maximum 
> result of this subtraction is defined by the RCU_FANOUT or other srcu 
> level-spread values assigned by rcu_init_levelspread(), which can indeed 
> cause the signed 32-bit integer literal ("1") to overflow when shifted 
> by any value greater than 31. This analysis should be added to the 
> commit message so the impact of the issue can be understood.

Another effect that might be worth mentioning in the commit message is 
what happens with the sign-carry for "1 << 31" when it is promoted from 
signed 32-bit integer to unsigned long on a 64-bit kernel: it translates 
to 0xffffffff80000000, which is certainly not what is expected here.

Thanks,

Mathieu


> 
> I also notice this in the same file:
> 
> srcu_schedule_cbs_snp():
> 
>          for (cpu = snp->grplo; cpu <= snp->grphi; cpu++) {
>                  if (!(mask & (1 << (cpu - snp->grplo))))
>                          continue;
> 
> Which should be fixed at the same time.
> 
> Thanks,
> 
> Mathieu
> 
>>       }
>>       smp_store_release(&ssp->srcu_sup->srcu_size_state, 
>> SRCU_SIZE_WAIT_BARRIER);
>>       return true;
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com


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

end of thread, other threads:[~2023-09-02 14:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-01  9:53 [PATCH] srcu: The value may overflow Denis Arefev
2023-09-01 13:31 ` Mathieu Desnoyers
2023-09-02 14:17   ` Mathieu Desnoyers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®