[PATCH net] flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

[PATCH net] flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

[Eric Dumazet]

bpf_flow_dissect() sanitizes the offsets returned by the BPF program
with clamp_t(u16, ..., hlen).

If hlen is bigger than 65535, the upper bound is truncated before
the comparison. For instance, with hlen == 65536, both nhoff and
thoff are forced to zero, even if the program returned sane values.

This is the same class of bug as the one fixed in commit 99bda1ecbd56
("flow_dissector: avoid u16 truncation of skb->len when computing
thoff"). That fix does not cover the BPF path, because
__skb_flow_dissect() returns early when a BPF flow dissector
handles the packet.

struct bpf_flow_keys stores nhoff and thoff as u16, so cap hlen
to U16_MAX before clamping.

Found by sashiko while reviewing the commit above.

Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
Assisted-by: LLM
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
---
 net/core/flow_dissector.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 27d8a01bc92306ff043389b4fde2d24af97d3106..1be6c739e3c718b4561195a20e49cc3911874af1 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -1023,6 +1023,8 @@ u32 bpf_flow_dissect(struct bpf_prog *prog, struct bpf_flow_dissector *ctx,
 
 	result = bpf_prog_run_pin_on_cpu(prog, ctx);
 
+	/* bpf_flow_keys offsets are u16: do not let @hlen be truncated. */
+	hlen = min_t(int, hlen, U16_MAX);
 	flow_keys->nhoff = clamp_t(u16, flow_keys->nhoff, nhoff, hlen);
 	flow_keys->thoff = clamp_t(u16, flow_keys->thoff,
 				   flow_keys->nhoff, hlen);
-- 
2.53.0

Re: [PATCH net] flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

[Eric Dumazet]

On 10/7/26 07:00, netdev-bot+sinfo@kernel.org wrote:
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>   - Whether the issue was actually triggered, or is only theoretical
>     (e.g. found by code inspection). If it was triggered please include
>     the symptoms, like the stack trace or error messages.

Changelog stated: Found by sashiko while reviewing the commit above.


> 
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Re: [PATCH net] flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

[Jakub Kicinski]

On Wed, 7 Oct 2026 07:03:16 +0200 Eric Dumazet wrote:
> > This is an automated message. This series looks like a fix, but its
> > commit messages seem to be missing some information:
> > 
> >   - Whether the issue was actually triggered, or is only theoretical
> >     (e.g. found by code inspection). If it was triggered please include
> >     the symptoms, like the stack trace or error messages.  
> 
> Changelog stated: Found by sashiko while reviewing the commit above.

FWIW the AI is asking if PoC was constructed to validate that the issue
can be triggered. I spent some time polishing this message but it's far
from perfect. Not sure how to make it clear & concise :(

Re: [PATCH net] flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed,  7 Oct 2026 06:56:15 +0200 you wrote:
> bpf_flow_dissect() sanitizes the offsets returned by the BPF program
> with clamp_t(u16, ..., hlen).
> 
> If hlen is bigger than 65535, the upper bound is truncated before
> the comparison. For instance, with hlen == 65536, both nhoff and
> thoff are forced to zero, even if the program returned sane values.
> 
> [...]

Here is the summary with links:
  - [net] flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()
    https://git.kernel.org/netdev/net/c/f202578efc73

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net] flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

[Eric Dumazet]

Le jeu. 8 oct. 2026 à 02:56, Jakub Kicinski <kuba@kernel.org> a écrit :
>
> On Wed, 7 Oct 2026 07:03:16 +0200 Eric Dumazet wrote:
> > > This is an automated message. This series looks like a fix, but its
> > > commit messages seem to be missing some information:
> > >
> > >   - Whether the issue was actually triggered, or is only theoretical
> > >     (e.g. found by code inspection). If it was triggered please include
> > >     the symptoms, like the stack trace or error messages.
> >
> > Changelog stated: Found by sashiko while reviewing the commit above.
>
> FWIW the AI is asking if PoC was constructed to validate that the issue
> can be triggered. I spent some time polishing this message but it's far
> from perfect. Not sure how to make it clear & concise :(

I was planning to extend the existing selftests in net-next, would it
help to mention
such a plan/followup in the future?

Thanks.