Eric Woudstra <[email protected]> wrote:
> 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 <[email protected]>
> ---
> 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.
