netdev - Re: [PATCH v13 nf-next 1/3] netfilter: utils: nf_checksum(

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aGgt4dUF2AsDXzdX@strlen.de>
Date: Fri, 4 Jul 2025 21:39:13 +0200
From: Florian Westphal <fw@...len.de>
To: Eric Woudstra <ericwouds@...il.com>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
	Jozsef Kadlecsik <kadlec@...filter.org>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	Ido Schimmel <idosch@...dia.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, netfilter-devel@...r.kernel.org,
	bridge@...ts.linux.dev, netdev@...r.kernel.org
Subject: Re: [PATCH v13 nf-next 1/3] netfilter: utils: nf_checksum(_partial)
 correct data!=networkheader

Eric Woudstra <ericwouds@...il.com> 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 <ericwouds@...il.com>
> ---
>  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.