Subject: Re: [PATCH net] netfilter: nf_flow_table_offload: fix heap overflow in flow_action_entry_next()

From: Hyunwoo Kim <[email-masked]>
Date: Mon, 16 Mar 2026 23:17:16 +0900

On Mon, Mar 16, 2026 at 12:48:33PM +0100, Florian Westphal wrote:
> Hyunwoo Kim <[email-masked]> wrote:
> > > Ping.  I'm not even sure if there is a bug to begin with, see Pablos
> > 
> > Sorry for the late reply.
> > 
> > To clarify, I triggered the overflow using a dummy device that accepts
> > TC_SETUP_FT, as I don't have real offload-capable hardware. The 17 entry
> > scenario requires double VLAN (QinQ) + IPv6 + SNAT + DNAT simultaneously,
> > which is unlikely in real-world deployments, so it is hypothetical.
> 
> If you triggered it, its not hyptothetical and needs to be fixed.
> 
> > > Normally there should be a check that prevents such a configuration.
> > > If thats missing, please add one instead of increasing this define.
> > 
> > So, should I send a v2 with a bounds check, or drop this patch?
> 
> Yes, please send a v2 that prevents the overflow at configuration time.

hmm. So, based on what you said, I assume the run-time check would look 
something like this?

diff --git a/net/netfilter/nf_flow_table_offload.c b/net/netfilter/nf_flow_table_offload.c
index 9b677e116487..69ffefbdd5e8 100644
--- a/net/netfilter/nf_flow_table_offload.c
+++ b/net/netfilter/nf_flow_table_offload.c
@@ -218,6 +218,9 @@ flow_action_entry_next(struct nf_flow_rule *flow_rule)
 {
        int i = flow_rule->rule->action.num_entries++;

+       if (WARN_ON_ONCE(i >= NF_FLOW_RULE_ACTION_MAX))
+               return NULL;
+
        return &flow_rule->rule->action.entries[i];
 }

However, if we add a runtime check in this way, all callers of 
flow_action_entry_next() would also need to handle a NULL return value, 
since none of them currently perform a null check.

Because of the potential risk, this would require modifying quite a number 
of call sites carefully. What do you think about this approach?