Re: [PATCH v13 nf-next 1/3] netfilter: utils: nf_checksum(_partial) correct data!=networkheader
From: Florian Westphal <fw@strlen.de>
Date: 2025-07-04 19:39:15
Also in:
bridge, netfilter-devel
Eric Woudstra [off-list ref] wrote:
quoted hunk ↗ jump to hunk
In the conntrack hook it may not always be the case that: skb_network_header(skb) == skb->data. This is problematic when L4 function nf_conntrack_handle_packet() is accessing L3 data. This function uses thoff and ip_hdr() to finds it's data. But it also calculates the checksum. nf_checksum() and nf_checksum_partial() both use lower skb-checksum functions that are based on using skb->data. When skb_network_header(skb) != skb->data, adjust accordingly, so that the checksum is calculated correctly. Signed-off-by: Eric Woudstra <redacted> --- net/netfilter/utils.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)diff --git a/net/netfilter/utils.c b/net/netfilter/utils.c index 008419db815a..daee035c25b8 100644 --- a/net/netfilter/utils.c +++ b/net/netfilter/utils.c@@ -124,16 +124,21 @@ __sum16 nf_checksum(struct sk_buff *skb, unsigned int hook, unsigned int dataoff, u8 protocol, unsigned short family) { + unsigned int nhpull = skb_network_header(skb) - skb->data; __sum16 csum = 0; + if (!pskb_may_pull(skb, nhpull)) + return -ENOMEM;
Hmm. Not sure about this. We should really audit all conntrack users
to make sure the network header is in the linear area, i.e.
ip_hdr() and friends return the right value, even though skb->data !=
skb_network_header().
Such may_pull, in case of skb->head reallocation, invalidate a pointer
to e.g. ethernet header in the caller.
No idea if we have callers that do this, I did not check, but such
"hidden" pulls tend to cause hard to spot bugs.
Maybe use
if (WARN_ON_ONCE(skb_pointer_if_linear())
return 0;
instead? That allows to track down any offenders. Given conntrack
takes presence of the l3 header in the linear area for granted, I don't
see how this can ever trigger. You could also use
DEBUG_NET_WARN_ON_ONCE if you prefer, given this condition should never
be true anyway.