[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?
---
net/sched/cls_flower.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index e960a46b0520..a326fbfe4339 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -1153,6 +1153,9 @@ static int fl_set_geneve_opt(const struct nlattr *nla, struct fl_flow_key *key,
if (option_len > sizeof(struct geneve_opt))
data_len = option_len - sizeof(struct geneve_opt);
+ if (key->enc_opts.len > FLOW_DIS_TUN_OPTS_MAX - 4)
+ return -ERANGE;
+
opt = (struct geneve_opt *)&key->enc_opts.data[key->enc_opts.len];
memset(opt, 0xff, option_len);
opt->length = data_len / 4;
--
2.34.1