[PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[Toke Høiland-Jørgensen]

Tetsuo pointed out that without an explicit cast, the cost calculation for
devmap_hash type maps could overflow on 32-bit builds. This adds the
missing cast.

Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
---
 kernel/bpf/devmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index a0a1153da5ae..e34fac6022eb 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -128,7 +128,7 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
 
 		if (!dtab->n_buckets) /* Overflow check */
 			return -EINVAL;
-		cost += sizeof(struct hlist_head) * dtab->n_buckets;
+		cost += (u64) sizeof(struct hlist_head) * dtab->n_buckets;
 	}
 
 	/* if map size is larger than memlock limit, reject it */
-- 
2.23.0

Re: [PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[Jakub Kicinski]

On Thu, 17 Oct 2019 12:57:02 +0200, Toke Høiland-Jørgensen wrote:
> Tetsuo pointed out that without an explicit cast, the cost calculation for
> devmap_hash type maps could overflow on 32-bit builds. This adds the
> missing cast.
> 
> Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
> Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> ---
>  kernel/bpf/devmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index a0a1153da5ae..e34fac6022eb 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -128,7 +128,7 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
>  
>  		if (!dtab->n_buckets) /* Overflow check */
>  			return -EINVAL;
> -		cost += sizeof(struct hlist_head) * dtab->n_buckets;
> +		cost += (u64) sizeof(struct hlist_head) * dtab->n_buckets;

array_size()?

>  	}
>  
>  	/* if map size is larger than memlock limit, reject it */

Re: [PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[Toke Høiland-Jørgensen]

Jakub Kicinski <jakub.kicinski@netronome.com> writes:

> On Thu, 17 Oct 2019 12:57:02 +0200, Toke Høiland-Jørgensen wrote:
>> Tetsuo pointed out that without an explicit cast, the cost calculation for
>> devmap_hash type maps could overflow on 32-bit builds. This adds the
>> missing cast.
>> 
>> Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
>> Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> ---
>>  kernel/bpf/devmap.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
>> index a0a1153da5ae..e34fac6022eb 100644
>> --- a/kernel/bpf/devmap.c
>> +++ b/kernel/bpf/devmap.c
>> @@ -128,7 +128,7 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
>>  
>>  		if (!dtab->n_buckets) /* Overflow check */
>>  			return -EINVAL;
>> -		cost += sizeof(struct hlist_head) * dtab->n_buckets;
>> +		cost += (u64) sizeof(struct hlist_head) * dtab->n_buckets;
>
> array_size()?

Well, array_size does this:

	if (check_mul_overflow(a, b, &bytes))
		return SIZE_MAX;

However, we don't to return SIZE_MAX on overflow, we want the
calculation itself to be done in 64 bits so it won't overflow... Or?

-Toke

Re: [PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[Yonghong Song]

On 10/17/19 3:57 AM, Toke Høiland-Jørgensen wrote:
> Tetsuo pointed out that without an explicit cast, the cost calculation for
> devmap_hash type maps could overflow on 32-bit builds. This adds the
> missing cast.
> 
> Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
> Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>

Acked-by: Yonghong Song <yhs@fb.com>

> ---
>   kernel/bpf/devmap.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index a0a1153da5ae..e34fac6022eb 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -128,7 +128,7 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
>   
>   		if (!dtab->n_buckets) /* Overflow check */
>   			return -EINVAL;
> -		cost += sizeof(struct hlist_head) * dtab->n_buckets;
> +		cost += (u64) sizeof(struct hlist_head) * dtab->n_buckets;
>   	}
>   
>   	/* if map size is larger than memlock limit, reject it */
> 

Re: [PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[Jakub Kicinski]

On Fri, 18 Oct 2019 11:15:39 +0200, Toke Høiland-Jørgensen wrote:
> Jakub Kicinski <jakub.kicinski@netronome.com> writes:
> 
> > On Thu, 17 Oct 2019 12:57:02 +0200, Toke Høiland-Jørgensen wrote:  
> >> Tetsuo pointed out that without an explicit cast, the cost calculation for
> >> devmap_hash type maps could overflow on 32-bit builds. This adds the
> >> missing cast.
> >> 
> >> Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
> >> Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> >> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> >> ---
> >>  kernel/bpf/devmap.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> >> index a0a1153da5ae..e34fac6022eb 100644
> >> --- a/kernel/bpf/devmap.c
> >> +++ b/kernel/bpf/devmap.c
> >> @@ -128,7 +128,7 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
> >>  
> >>  		if (!dtab->n_buckets) /* Overflow check */
> >>  			return -EINVAL;
> >> -		cost += sizeof(struct hlist_head) * dtab->n_buckets;
> >> +		cost += (u64) sizeof(struct hlist_head) * dtab->n_buckets;  
> >
> > array_size()?  
> 
> Well, array_size does this:
> 
> 	if (check_mul_overflow(a, b, &bytes))
> 		return SIZE_MAX;
> 
> However, we don't to return SIZE_MAX on overflow, we want the
> calculation itself to be done in 64 bits so it won't overflow... Or?

Note that array_size calculates on size_t, so it should be fine.
But looking at it, it seems all of this code uses the (u64) cast, 
so I guess that's fine. Clean up for another day :)

Re: [PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[Alexei Starovoitov]

On Fri, Oct 18, 2019 at 8:36 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Tetsuo pointed out that without an explicit cast, the cost calculation for
> devmap_hash type maps could overflow on 32-bit builds. This adds the
> missing cast.
>
> Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
> Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>

gmail delivery lags by a day :(
I applied this patch along with Yonghong's ack to bpf tree
(though I don't have it in my mail box, but it's there in patchworks).

I'm not sure that cleanup Jakub is proposing is possible or better.
Not everything is array_size here and in other places
where cost is computed. u64 is imo much cleaner.

Re: [PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[Jakub Kicinski]

On Fri, 18 Oct 2019 16:25:24 -0700, Alexei Starovoitov wrote:
> I'm not sure that cleanup Jakub is proposing is possible or better.
> Not everything is array_size here and in other places
> where cost is computed. u64 is imo much cleaner.

Right, adding multiple components with size_t is going to be
unnecessarily tricky.

Re: [PATCH bpf] xdp: Prevent overflow in devmap_hash cost calculation for 32-bit builds

[David Miller]

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Fri, 18 Oct 2019 16:25:24 -0700

> gmail delivery lags by a day :(

Sorry, I'm working on that.