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

["Alice Mikityanska" <alice.kernel@fastmail.im>]

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