[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <55aca58a.a2c0e.188f54a2741.Coremail.linma@zju.edu.cn>
Date: Mon, 26 Jun 2023 09:20:57 +0800 (GMT+08:00)
From: "Lin Ma" <linma@....edu.cn>
To: "Alexey Dobriyan" <adobriyan@...il.com>
Cc: steffen.klassert@...unet.com, herbert@...dor.apana.org.au,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, simon.horman@...igine.com
Subject: Re: [PATCH v2] net: xfrm: Fix xfrm_address_filter OOB read
Hello Alexey,
(sorry last mail just reply to one ..)
>
> > + if (filter->splen >= (sizeof(xfrm_address_t) << 3) ||
> > + filter->dplen >= (sizeof(xfrm_address_t) << 3)) {
>
> Please multiply by 8 if you want to multiply by 8.
>
Thanks for reminding.
As I told in the commit message, this checking code is just copy from the function pfkey_dump (net/key/af_key.c), which like
if ((xfilter->sadb_x_filter_splen >=
(sizeof(xfrm_address_t) << 3)) ||
(xfilter->sadb_x_filter_dplen >=
(sizeof(xfrm_address_t) << 3))) {
mutex_unlock(&pfk->dump_lock);
return -EINVAL;
}
I think the left shift 3 is okay as the actual calculation on those lengths is right shift + left shift (see in addr_match() function).
> Should it be "splen > 8 * sizeof()" ?
Good question. It seems that the filter length is legal to reach the maximum length. So should I send another patch that allows the checking code in pfkey_dump (net/key/af_key.c) to change to > instead of >= ?
Regards
Lin
Powered by blists - more mailing lists