[PATCH net] netfilter: flowtable: Saturate 16-bit flow_tuple->mtu

[PATCH net] netfilter: flowtable: Saturate 16-bit flow_tuple->mtu

[Alice Mikityanska]

From: Alice Mikityanska <alice@isovalent.com>

ip6_dst_mtu_maybe_forward clamps its return value to IP6_MAX_MTU, which
is 40 bytes bigger than U16_MAX. While it can be a valid IPv6 MTU (IPv6
payload_len doesn't include the header), this value is assigned to the
16-bit flow_tuple->mtu in flow_offload_fill_route.

To avoid the overflow, use U16_MAX for all MTUs bigger than 65535. Since
flow_tuple->mtu is just a threshold for the software flowtable fast
path, packets exceeding it won't be dropped, but rather punted to the
normal forwarding path: nf_flow_offload_ipv6_forward returns 0, and
nf_flow_offload_ipv6_hook returns NF_ACCEPT.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901195714.673548-1-alice.kernel%40fastmail.im
Fixes: 4f3780c004ef ("netfilter: nf_flow_table: cache mtu in struct flow_offload_tuple")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
---
 net/netfilter/nf_flow_table_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
index 03241d4bfd5e..8f15540ae206 100644
--- a/net/netfilter/nf_flow_table_core.c
+++ b/net/netfilter/nf_flow_table_core.c
@@ -107,7 +107,8 @@ static int flow_offload_fill_route(struct flow_offload *flow,
 		flow_tuple->mtu = ip_dst_mtu_maybe_forward(dst, true);
 		break;
 	case NFPROTO_IPV6:
-		flow_tuple->mtu = ip6_dst_mtu_maybe_forward(dst, true);
+		flow_tuple->mtu = min(ip6_dst_mtu_maybe_forward(dst, true),
+				      U16_MAX);
 		break;
 	}
 
-- 
2.55.0

Re: [PATCH net] netfilter: flowtable: Saturate 16-bit flow_tuple->mtu

[Pablo Neira Ayuso]

Hi,

On Thu, Sep 10, 2026 at 07:20:52PM +0300, Alice Mikityanska wrote:
> From: Alice Mikityanska <alice@isovalent.com>
> 
> ip6_dst_mtu_maybe_forward clamps its return value to IP6_MAX_MTU, which
> is 40 bytes bigger than U16_MAX. While it can be a valid IPv6 MTU (IPv6
> payload_len doesn't include the header), this value is assigned to the
> 16-bit flow_tuple->mtu in flow_offload_fill_route.
> 
> To avoid the overflow, use U16_MAX for all MTUs bigger than 65535. Since
> flow_tuple->mtu is just a threshold for the software flowtable fast
> path, packets exceeding it won't be dropped, but rather punted to the
> normal forwarding path: nf_flow_offload_ipv6_forward returns 0, and
> nf_flow_offload_ipv6_hook returns NF_ACCEPT.
> 
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901195714.673548-1-alice.kernel%40fastmail.im
> Fixes: 4f3780c004ef ("netfilter: nf_flow_table: cache mtu in struct flow_offload_tuple")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Alice Mikityanska <alice@isovalent.com>
> ---
>  net/netfilter/nf_flow_table_core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
> index 03241d4bfd5e..8f15540ae206 100644
> --- a/net/netfilter/nf_flow_table_core.c
> +++ b/net/netfilter/nf_flow_table_core.c
> @@ -107,7 +107,8 @@ static int flow_offload_fill_route(struct flow_offload *flow,
>  		flow_tuple->mtu = ip_dst_mtu_maybe_forward(dst, true);
>  		break;
>  	case NFPROTO_IPV6:
> -		flow_tuple->mtu = ip6_dst_mtu_maybe_forward(dst, true);
> +		flow_tuple->mtu = min(ip6_dst_mtu_maybe_forward(dst, true),
> +				      U16_MAX);

This reminds me we should not catch the mtu.

>  		break;
>  	}
>  
> -- 
> 2.55.0
> 

Re: [PATCH net] netfilter: flowtable: Saturate 16-bit flow_tuple->mtu

[Alice Mikityanska]

On Fri, Sep 11, 2026, at 14:31, Pablo Neira Ayuso wrote:
> Hi,
>
> On Thu, Sep 10, 2026 at 07:20:52PM +0300, Alice Mikityanska wrote:
>> From: Alice Mikityanska <alice@isovalent.com>
>> 
>> ip6_dst_mtu_maybe_forward clamps its return value to IP6_MAX_MTU, which
>> is 40 bytes bigger than U16_MAX. While it can be a valid IPv6 MTU (IPv6
>> payload_len doesn't include the header), this value is assigned to the
>> 16-bit flow_tuple->mtu in flow_offload_fill_route.
>> 
>> To avoid the overflow, use U16_MAX for all MTUs bigger than 65535. Since
>> flow_tuple->mtu is just a threshold for the software flowtable fast
>> path, packets exceeding it won't be dropped, but rather punted to the
>> normal forwarding path: nf_flow_offload_ipv6_forward returns 0, and
>> nf_flow_offload_ipv6_hook returns NF_ACCEPT.
>> 
>> Reported-by: Sashiko <sashiko-bot@kernel.org>
>> Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901195714.673548-1-alice.kernel%40fastmail.im
>> Fixes: 4f3780c004ef ("netfilter: nf_flow_table: cache mtu in struct flow_offload_tuple")
>> Assisted-by: Codex:gpt-5.6-sol
>> Signed-off-by: Alice Mikityanska <alice@isovalent.com>
>> ---
>>  net/netfilter/nf_flow_table_core.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
>> index 03241d4bfd5e..8f15540ae206 100644
>> --- a/net/netfilter/nf_flow_table_core.c
>> +++ b/net/netfilter/nf_flow_table_core.c
>> @@ -107,7 +107,8 @@ static int flow_offload_fill_route(struct flow_offload *flow,
>>  		flow_tuple->mtu = ip_dst_mtu_maybe_forward(dst, true);
>>  		break;
>>  	case NFPROTO_IPV6:
>> -		flow_tuple->mtu = ip6_dst_mtu_maybe_forward(dst, true);
>> +		flow_tuple->mtu = min(ip6_dst_mtu_maybe_forward(dst, true),
>> +				      U16_MAX);
>
> This reminds me we should not catch the mtu.

Sorry, I may not have enough context here... Do you mean "cache the
mtu"? Should I go with a different approach about fixing this bug, or
should I drop the optimization instead of fixing it?

Thanks,
Alice

>>  		break;
>>  	}
>>  
>> -- 
>> 2.55.0
>>