Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ebdc1731-3647-8b58-c66c-db5bb09f5bfa@gmail.com>
Date:   Wed, 31 May 2023 18:05:29 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH] net: sched: fix possible OOB write in fl_set_geneve_opt()
To:     Simon Horman <simon.horman@corigine.com>
Cc:     jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us,
        davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
        pabeni@redhat.com, simon.horman@netronome.com,
        pieter.jansen-van-vuuren@amd.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20230529043615.4761-1-hbh25y@gmail.com>
 <ZHXf29es/yh3r6jq@corigine.com>
 <e9925aef-fefc-24b9-dea3-bd3bcca01b35@gmail.com>
 <ZHb/nPuTMja3giSP@corigine.com>
Content-Language: en-US
From:   Hangyu Hua <hbh25y@gmail.com>
In-Reply-To: <ZHb/nPuTMja3giSP@corigine.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 31/5/2023 16:04, Simon Horman wrote:
> On Wed, May 31, 2023 at 01:38:49PM +0800, Hangyu Hua wrote:
>> On 30/5/2023 19:36, Simon Horman wrote:
>>> [Updated Pieter's email address, dropped old email address of mine]
>>>
>>> On Mon, May 29, 2023 at 12:36:15PM +0800, Hangyu Hua wrote:
>>>> If we send two TCA_FLOWER_KEY_ENC_OPTS_GENEVE packets and their total
>>>> size is 252 bytes(key->enc_opts.len = 252) then
>>>> key->enc_opts.len = opt->length = data_len / 4 = 0 when the third
>>>> TCA_FLOWER_KEY_ENC_OPTS_GENEVE packet enters fl_set_geneve_opt. This
>>>> bypasses the next bounds check and results in an out-of-bounds.
>>>>
>>>> Fixes: 0a6e77784f49 ("net/sched: allow flower to match tunnel options")
>>>> Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
>>>
>>> Hi Hangyu Hua,
>>>
>>> Thanks. I think I see the problem too.
>>> But I do wonder, is this more general than Geneve options?
>>> That is, can this occur with any sequence of options, that
>>> consume space in enc_opts (configured in fl_set_key()) that
>>> in total are more than 256 bytes?
>>>
>>
>> I think you are right. It is a good idea to add check in fl_set_vxlan_opt
>> and fl_set_erspan_opt and fl_set_gtp_opt too.
>> But they should be submitted as other patches. fl_set_geneve_opt has already
>> check this with the following code:
>>
>> static int fl_set_geneve_opt(const struct nlattr *nla, struct fl_flow_key
>> *key,
>> 			     int depth, int option_len,
>> 			     struct netlink_ext_ack *extack)
>> {
>> ...
>> 		if (new_len > FLOW_DIS_TUN_OPTS_MAX) {
>> 			NL_SET_ERR_MSG(extack, "Tunnel options exceeds max size");
>> 			return -ERANGE;
>> 		}
>> ...
>> }
>>
>> This bug will only be triggered under this special
>> condition(key->enc_opts.len = 252). So I think it will be better understood
>> by submitting this patch independently.
> 
> A considered approach sounds good to me.
> 
> I do wonder, could the bounds checks be centralised in the caller?
> Maybe not if it doesn't know the length that will be consumed.
> 

This may make code more complex. I am not sure if it is necessary to do 
this.

>> By the way, I think memset's third param should be option_len in
>> fl_set_vxlan_opt and fl_set_erspan_opt. Do I need to submit another patch to
>> fix all these issues?
> 
> I think that in general one fix per patch is best.

I see. I will try to handle these issues.

> 
> Some minor nits.
> 
> 1. As this is a fix for networking code it is probably targeted
>     at the net, as opposed to net-next, tree. This should be indicated
>     in the patch subject.
> 
> 	 Subject: [PATCH net v2] ...
> 
> 2. I think the usual patch prefix for this file, of late,
>     has been 'net/sched: flower: '
> 
> 	 Subject: [PATCH net v2]  net/sched: flower: ...
> 

Get it. I will send a v2 later.