From: Joao Moreira <[email protected]>
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 UINT_MAX.
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,
Joao Moreira (2):
Make loop indexes unsigned
Make num_actions unsigned
net/core/flow_offload.c | 4 ++--
net/netfilter/nf_tables_offload.c | 6 +++++-
2 files changed, 7 insertions(+), 3 deletions(-)
--
2.42.0
From: Joao Moreira <[email protected]>
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 UINT_MAX when being incremented.
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 <[email protected]>
---
net/netfilter/nf_tables_offload.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
index 12ab78fa5d84..d25088791a74 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,9 @@ struct nft_flow_rule *nft_flow_rule_create(struct net *net,
expr->ops->offload_action(expr))
num_actions++;
+ if (num_actions == UINT_MAX)
+ return ERR_PTR(-ENOMEM);
+
expr = nft_expr_next(expr);
}
--
2.42.0
From: Joao Moreira <[email protected]>
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 <[email protected]>
---
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
On Wed, Sep 27, 2023 at 10:25:03AM +0200, Pablo Neira Ayuso wrote:
> On Tue, Sep 26, 2023 at 07:02:19PM -0700, [email protected] wrote:
> > From: Joao Moreira <[email protected]>
> >
> > 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 UINT_MAX.
> >
> > This issue was observed by the commit author while reviewing a write-up
> > regarding a CVE within the same subsystem [1].
>
> I keep spinning around this, this is not really an issue.
>
> No frontend uses this amount of actions.
>
> Probably cap this to uint16_t because 2^16 actions is more than
> sufficient by now.
Actually, even 2^8 actions is more than enough by now.
On Tue, Sep 26, 2023 at 07:02:19PM -0700, [email protected] wrote:
> From: Joao Moreira <[email protected]>
>
> 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 UINT_MAX.
>
> This issue was observed by the commit author while reviewing a write-up
> regarding a CVE within the same subsystem [1].
I keep spinning around this, this is not really an issue.
No frontend uses this amount of actions.
Probably cap this to uint16_t because 2^16 actions is more than
sufficient by now.
From: [email protected]
> Sent: 27 September 2023 03:02
>
> From: Joao Moreira <[email protected]>
>
> 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 UINT_MAX when being incremented.
>
> 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 <[email protected]>
> ---
> net/netfilter/nf_tables_offload.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
> index 12ab78fa5d84..d25088791a74 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,9 @@ struct nft_flow_rule *nft_flow_rule_create(struct net *net,
> expr->ops->offload_action(expr))
> num_actions++;
>
> + if (num_actions == UINT_MAX)
> + return ERR_PTR(-ENOMEM);
> +
> expr = nft_expr_next(expr);
The code is going to 'crash and burn' well before the counter
can possibly overflow.
nft_expr_next() is ((void *)expr) + expr->ops->size;
It is far more likely that has got setup wrong than the
count is too big.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)