On Thu, Sep 28, 2023 at 07:55:09PM -0700, Joao Moreira wrote: > On 2023-09-28 06:43, Pablo Neira Ayuso wrote: > > On Wed, Sep 27, 2023 at 09:47:15AM -0700, joao@xxxxxxxxxxxxxxxxxx wrote: > > > From: Joao Moreira <joao.moreira@xxxxxxxxx> > > > > > > Currently, in nft_flow_rule_create function, num_actions is a signed > > > integer. Yet, it is processed within a loop which increments its > > > value. To prevent an overflow from occurring, make it unsigned and > > > also check if it reaches 256 when being incremented. > > > > > > Accordingly to discussions around v2, 256 actions are more than enough > > > for the frontend actions. > > > > > > After checking with maintainers, it was mentioned that front-end will > > > cap the num_actions value and that it is not possible to reach such > > > condition for an overflow. Yet, for correctness, it is still better to > > > fix this. > > > > > > This issue was observed by the commit author while reviewing a > > > write-up > > > regarding a CVE within the same subsystem [1]. > > > > > > 1 - https://nickgregory.me/post/2022/03/12/cve-2022-25636/ > > > > Yes, but this is not related to the netfilter subsystem itself, this > > harderning is good to have for the flow offload infrastructure in > > general. > > Right, I'll try to look up where this would fit in then. I'm not an expert > in the subsystem at all, so should take a minute or two for me to get to it > and send a v4. Thanks. > > > struct nft_expr *expr; > > > > > > expr = nft_expr_first(rule); > > > @@ -99,6 +100,10 @@ struct nft_flow_rule > > > *nft_flow_rule_create(struct net *net, > > > expr->ops->offload_action(expr)) > > > num_actions++; > > > > > > + /* 2^8 is enough for frontend actions, avoid overflow */ > > > + if (num_actions == 256) > > > > This cap is not specific of nf_tables, it should apply to all other > > subsystems. This is the wrong spot. > > Any pointers regarding where I should look at? See flow_rule_alloc().
