On Thu, Sep 28, 2023 at 07:55:09PM -0700, Joao Moreira wrote:

On 2023-09-28 06:43, Pablo Neira Ayuso wrote:

quoted

On Wed, Sep 27, 2023 at 09:47:15AM -0700, joao@overdrivepizza.com wrote:

quoted

From: Joao Moreira <redacted>

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.

quoted

quoted

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