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

[PATCH v3 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
making the variable unsigned and ensuring that it returns an error if
its value reaches 256. The set limit value comes from discussions in the
mailing list where 256 was identified as a more than enough for the
frontend actions.

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/

Tks,

v2:
- Identify overflow by making num_actions unsigned and checking if it
  reaches UINT_MAX instead of looking for its signedness.
v3:
- Avoid overflow by checking if num_actions reaches 256 (which is
  enough) instead of UINT_MAX.

Joao Moreira (2):
  Make loop indexes unsigned
  Make num_actions unsigned

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

-- 
2.42.0

[PATCH v3 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.

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/

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

Re: [PATCH v3 1/2] Make loop indexes unsigned

[Pablo Neira Ayuso]

On Wed, Sep 27, 2023 at 09:47:14AM -0700, joao@overdrivepizza.com wrote:
> 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.
> 
> 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/
> 
> 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;

With the 2^8 cap, I don't think this patch is required anymore.

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

Re: [PATCH v3 1/2] Make loop indexes unsigned

[Joao Moreira]

On 2023-09-28 06:40, Pablo Neira Ayuso wrote:
> On Wed, Sep 27, 2023 at 09:47:14AM -0700, joao@overdrivepizza.com 
> wrote:
>> 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.
>> 
>> 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/
>> 
>> 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;
> 
> With the 2^8 cap, I don't think this patch is required anymore.

Hm. While I understand that there is not a significant menace haunting 
this... would it be good for (1) type correctness and (2) prevent that 
things blow up if something changes and someone misses this spot?

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

Re: [PATCH v3 1/2] Make loop indexes unsigned

[Pablo Neira Ayuso]

On Thu, Sep 28, 2023 at 07:53:14PM -0700, Joao Moreira wrote:
> On 2023-09-28 06:40, Pablo Neira Ayuso wrote:
> > On Wed, Sep 27, 2023 at 09:47:14AM -0700, joao@overdrivepizza.com wrote:
> > > 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.
> > > 
> > > 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/
> > > 
> > > 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;
> > 
> > With the 2^8 cap, I don't think this patch is required anymore.
> 
> Hm. While I understand that there is not a significant menace haunting
> this... would it be good for (1) type correctness and (2) prevent that
> things blow up if something changes and someone misses this spot?

Nothing is going to change, please remove unnecesary updates. Capping
to 2^8 for all hardware offload subsystems is sufficient by now. If
someone needs more than that, it will have to justify it.

[PATCH v3 2/2] Make num_actions unsigned

[joao]

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

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/

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

diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
index 12ab78fa5d84..9a86db1f0e07 100644
--- a/net/netfilter/nf_tables_offload.c
+++ b/net/netfilter/nf_tables_offload.c
@@ -90,7 +90,8 @@ struct nft_flow_rule *nft_flow_rule_create(struct net *net,
 {
 	struct nft_offload_ctx *ctx;
 	struct nft_flow_rule *flow;
-	int num_actions = 0, err;
+	unsigned int num_actions = 0;
+	int err;
 	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)
+			return ERR_PTR(-ENOMEM);
+
 		expr = nft_expr_next(expr);
 	}
 
-- 
2.42.0

Re: [PATCH v3 2/2] Make num_actions unsigned

[Pablo Neira Ayuso]

On Wed, Sep 27, 2023 at 09:47:15AM -0700, joao@overdrivepizza.com wrote:
> From: Joao Moreira <joao.moreira@intel.com>
> 
> 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.

> Signed-off-by: Joao Moreira <joao.moreira@intel.com>
> ---
>  net/netfilter/nf_tables_offload.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
> index 12ab78fa5d84..9a86db1f0e07 100644
> --- a/net/netfilter/nf_tables_offload.c
> +++ b/net/netfilter/nf_tables_offload.c
> @@ -90,7 +90,8 @@ struct nft_flow_rule *nft_flow_rule_create(struct net *net,
>  {
>  	struct nft_offload_ctx *ctx;
>  	struct nft_flow_rule *flow;
> -	int num_actions = 0, err;
> +	unsigned int num_actions = 0;
> +	int err;

reverse xmas tree.

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

Moreover, please, add a definition for this, no hardcoded values.

> +			return ERR_PTR(-ENOMEM);

Better E2BIG or similar, otherwise this propagates to userspace as
ENOMEM.

> +
>  		expr = nft_expr_next(expr);
>  	}
>  
> -- 
> 2.42.0
> 

Re: [PATCH v3 2/2] Make num_actions unsigned

[Joao Moreira]

On 2023-09-28 06:43, Pablo Neira Ayuso wrote:
> On Wed, Sep 27, 2023 at 09:47:15AM -0700, joao@overdrivepizza.com 
> wrote:
>> From: Joao Moreira <joao.moreira@intel.com>
>> 
>> 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.

> 
>> Signed-off-by: Joao Moreira <joao.moreira@intel.com>
>> ---
>>  net/netfilter/nf_tables_offload.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/net/netfilter/nf_tables_offload.c 
>> b/net/netfilter/nf_tables_offload.c
>> index 12ab78fa5d84..9a86db1f0e07 100644
>> --- a/net/netfilter/nf_tables_offload.c
>> +++ b/net/netfilter/nf_tables_offload.c
>> @@ -90,7 +90,8 @@ struct nft_flow_rule *nft_flow_rule_create(struct 
>> net *net,
>>  {
>>  	struct nft_offload_ctx *ctx;
>>  	struct nft_flow_rule *flow;
>> -	int num_actions = 0, err;
>> +	unsigned int num_actions = 0;
>> +	int err;
> 
> reverse xmas tree.

ack.

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

> 
> Moreover, please, add a definition for this, no hardcoded values.

Ack.

> 
>> +			return ERR_PTR(-ENOMEM);
> 
> Better E2BIG or similar, otherwise this propagates to userspace as
> ENOMEM.

Ack.

> 
>> +
>>  		expr = nft_expr_next(expr);
>>  	}
>> 
>> --
>> 2.42.0
>> 

Re: [PATCH v3 2/2] Make num_actions unsigned

[Pablo Neira Ayuso]

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@overdrivepizza.com wrote:
> > > From: Joao Moreira <joao.moreira@intel.com>
> > > 
> > > 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().