lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZHb/nPuTMja3giSP@corigine.com> Date: Wed, 31 May 2023 10:04:44 +0200 From: Simon Horman <simon.horman@...igine.com> To: Hangyu Hua <hbh25y@...il.com> Cc: jhs@...atatu.com, xiyou.wangcong@...il.com, jiri@...nulli.us, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, simon.horman@...ronome.com, pieter.jansen-van-vuuren@....com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] net: sched: fix possible OOB write in fl_set_geneve_opt() 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@...il.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. > 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. 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: ...
Powered by blists - more mailing lists