[PATCH 0/2] Prevent potential write out of bounds

[PATCH 0/2] Prevent potential write out of bounds

[joao]

From: Joao Moreira <joao.moreira@intel.com>

The function flow_rule_alloc in net/core/flow_offload.c [2] gets an
unsigned int num_actions (line 10) and later traverses the actions in
the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE.

Within the same file, the loop in the line 24 compares a signed int
(i) to an unsigned int (num_actions), and then uses i as an array
index. If an integer overflow happens, then the array within the loop
is wrongly indexed, causing a write out of bounds.

After checking with maintainers, it seems that the front-end caps the
maximum value of num_action, thus it is not possible to reach the given
write out of bounds, yet, still, to prevent disasters it is better to
fix the signedness here.

Similarly, also it is also good to ensure that an overflow won't happen
in net/netfilter/nf_tables_offload.c's function nft_flow_rule_create by
checking that num_actions is not negative.

Tks,

Joao Moreira (2):
  Make loop indexes unsigned
  Ensure num_actions is not a negative

 net/core/flow_offload.c           | 4 ++--
 net/netfilter/nf_tables_offload.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.41.0

[PATCH 1/2] Make loop indexes unsigned

[joao]

From: Joao Moreira <joao.moreira@intel.com>

Both flow_rule_alloc and offload_action_alloc functions received an
unsigned num_actions parameters which are then operated within a loop.
The index of this loop is declared as a signed int. If it was possible
to pass a large enough num_actions to these functions, it would lead to
an out of bounds write.

After checking with maintainers, it was mentioned that front-end will
cap the num_actions value and that it is not possible to reach this
function with such a large number. Yet, for correctness, it is still
better to fix this.

Signed-off-by: Joao Moreira <joao.moreira@intel.com>
---
 net/core/flow_offload.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c
index bc5169482710..bc3f53a09d8f 100644
--- a/net/core/flow_offload.c
+++ b/net/core/flow_offload.c
@@ -10,7 +10,7 @@
 struct flow_rule *flow_rule_alloc(unsigned int num_actions)
 {
 	struct flow_rule *rule;
-	int i;
+	unsigned int i;
 
 	rule = kzalloc(struct_size(rule, action.entries, num_actions),
 		       GFP_KERNEL);
@@ -31,7 +31,7 @@ EXPORT_SYMBOL(flow_rule_alloc);
 struct flow_offload_action *offload_action_alloc(unsigned int num_actions)
 {
 	struct flow_offload_action *fl_action;
-	int i;
+	unsigned int i;
 
 	fl_action = kzalloc(struct_size(fl_action, action.entries, num_actions),
 			    GFP_KERNEL);
-- 
2.41.0

[PATCH 2/2] Ensure num_actions is not a negative

[joao]

From: Joao Moreira <joao.moreira@intel.com>

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, check if num_actions is not only equal to 0,
but also not negative.

After checking with maintainers, it was mentioned that front-end will
cap the num_actions vlaue and that it is not possible to reach such
condition for an overflow. Yet, for correctness, it is still better to
fix this.

Signed-off-by: Joao Moreira <joao.moreira@intel.com>
---
 net/netfilter/nf_tables_offload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
index 12ab78fa5d84..20dbc95de895 100644
--- a/net/netfilter/nf_tables_offload.c
+++ b/net/netfilter/nf_tables_offload.c
@@ -102,7 +102,7 @@ struct nft_flow_rule *nft_flow_rule_create(struct net *net,
 		expr = nft_expr_next(expr);
 	}
 
-	if (num_actions == 0)
+	if (num_actions <= 0)
 		return ERR_PTR(-EOPNOTSUPP);
 
 	flow = nft_flow_rule_alloc(num_actions);
-- 
2.41.0

Re: [PATCH 2/2] Ensure num_actions is not a negative

[Pablo Neira Ayuso]

On Thu, Aug 31, 2023 at 06:04:37PM -0700, joao@overdrivepizza.com wrote:
> From: Joao Moreira <joao.moreira@intel.com>
> 
> 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, check if num_actions is not only equal to 0,
> but also not negative.
> 
> After checking with maintainers, it was mentioned that front-end will
> cap the num_actions vlaue and that it is not possible to reach such
> condition for an overflow. Yet, for correctness, it is still better to
> fix this.
> 
> Signed-off-by: Joao Moreira <joao.moreira@intel.com>
> ---
>  net/netfilter/nf_tables_offload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
> index 12ab78fa5d84..20dbc95de895 100644
> --- a/net/netfilter/nf_tables_offload.c
> +++ b/net/netfilter/nf_tables_offload.c
> @@ -102,7 +102,7 @@ struct nft_flow_rule *nft_flow_rule_create(struct net *net,
>  		expr = nft_expr_next(expr);
>  	}
>  
> -	if (num_actions == 0)
> +	if (num_actions <= 0)
>  		return ERR_PTR(-EOPNOTSUPP);

Better turn num_actions into unsigned int I'd suggest.

Next hypothetical problem would be an overflow in the number of
actions, you could check for UINT_MAX if you like here to report
ENOMEM.

Thanks.

>  	flow = nft_flow_rule_alloc(num_actions);
> -- 
> 2.41.0
> 

Re: [PATCH 0/2] Prevent potential write out of bounds

[Jakub Kicinski]

On Thu, 31 Aug 2023 18:04:35 -0700 joao@overdrivepizza.com wrote:
> The function flow_rule_alloc in net/core/flow_offload.c [2] gets an
> unsigned int num_actions (line 10) and later traverses the actions in
> the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE.
> 
> Within the same file, the loop in the line 24 compares a signed int
> (i) to an unsigned int (num_actions), and then uses i as an array
> index. If an integer overflow happens, then the array within the loop
> is wrongly indexed, causing a write out of bounds.
> 
> After checking with maintainers, it seems that the front-end caps the
> maximum value of num_action, thus it is not possible to reach the given
> write out of bounds, yet, still, to prevent disasters it is better to
> fix the signedness here.

How did you find this? The commit messages should include info
about how the issue was discovered.
-- 
pw-bot: cr

Re: [PATCH 0/2] Prevent potential write out of bounds

[Joao Moreira]

On 2023-08-31 18:28, Jakub Kicinski wrote:
> On Thu, 31 Aug 2023 18:04:35 -0700 joao@overdrivepizza.com wrote:
>> The function flow_rule_alloc in net/core/flow_offload.c [2] gets an
>> unsigned int num_actions (line 10) and later traverses the actions in
>> the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE.
>> 
>> Within the same file, the loop in the line 24 compares a signed int
>> (i) to an unsigned int (num_actions), and then uses i as an array
>> index. If an integer overflow happens, then the array within the loop
>> is wrongly indexed, causing a write out of bounds.
>> 
>> After checking with maintainers, it seems that the front-end caps the
>> maximum value of num_action, thus it is not possible to reach the 
>> given
>> write out of bounds, yet, still, to prevent disasters it is better to
>> fix the signedness here.
> 
> How did you find this? The commit messages should include info
> about how the issue was discovered.

Sure, I'll wait a bit longer for more suggestions and add the info in a 
next patch version.

Meanwhile, fwiiw, I stumbled on the bug when I was reading Nick 
Gregory's write-up on CVE-2022-25636 [1], which happens nearby but is 
not exactly this issue.

Tks,
Joao

[1] - https://nickgregory.me/post/2022/03/12/cve-2022-25636/

Re: [PATCH 0/2] Prevent potential write out of bounds

[Pablo Neira Ayuso]

On Thu, Aug 31, 2023 at 06:28:00PM -0700, Jakub Kicinski wrote:
> On Thu, 31 Aug 2023 18:04:35 -0700 joao@overdrivepizza.com wrote:
> > The function flow_rule_alloc in net/core/flow_offload.c [2] gets an
> > unsigned int num_actions (line 10) and later traverses the actions in
> > the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE.
> > 
> > Within the same file, the loop in the line 24 compares a signed int
> > (i) to an unsigned int (num_actions), and then uses i as an array
> > index. If an integer overflow happens, then the array within the loop
> > is wrongly indexed, causing a write out of bounds.
> > 
> > After checking with maintainers, it seems that the front-end caps the
> > maximum value of num_action, thus it is not possible to reach the given
> > write out of bounds, yet, still, to prevent disasters it is better to
> > fix the signedness here.
> 
> How did you find this? The commit messages should include info
> about how the issue was discovered.

This is net-next material IMO, none of the existing interfaces uses
such a large number of actions for this to be an issue.