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

From: Alice Mikityanska <redacted>

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

Hi,

On Thu, Sep 10, 2026 at 07:20:52PM +0300, Alice Mikityanska wrote:

This reminds me we should not catch the mtu.

 		break;
 	}
 
-- 
2.55.0

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:

quoted

From: Alice Mikityanska <redacted>

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

quoted

 		break;
 	}
 
-- 
2.55.0