Re: [PATCH] net: sched: fix possible OOB write in fl_set_geneve_opt()

From: Hangyu Hua
Date: Wed May 31 2023 - 06:05:40 EST

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@xxxxxxxxx>

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
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.