netdev - Re: [PATCH net v2] net: make skb_dst_force return true when dst is refcounted

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] [day] [month] [year] [list]

Message-Id: <20190629.110216.897222978158891297.davem@davemloft.net>
Date:   Sat, 29 Jun 2019 11:02:16 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     fw@...len.de
Cc:     netdev@...r.kernel.org, eric.dumazet@...il.com,
        netfilter-devel@...r.kernel.org
Subject: Re: [PATCH net v2] net: make skb_dst_force return true when dst is
 refcounted

From: Florian Westphal <fw@...len.de>
Date: Wed, 26 Jun 2019 20:40:45 +0200

> netfilter did not expect that skb_dst_force() can cause skb to lose its
> dst entry.
> 
> I got a bug report with a skb->dst NULL dereference in netfilter
> output path.  The backtrace contains nf_reinject(), so the dst might have
> been cleared when skb got queued to userspace.
> 
> Other users were fixed via
> if (skb_dst(skb)) {
> 	skb_dst_force(skb);
> 	if (!skb_dst(skb))
> 		goto handle_err;
> }
> 
> But I think its preferable to make the 'dst might be cleared' part
> of the function explicit.
> 
> In netfilter case, skb with a null dst is expected when queueing in
> prerouting hook, so drop skb for the other hooks.
> 
> v2:
>  v1 of this patch returned true in case skb had no dst entry.
>  Eric said:
>    Say if we have two skb_dst_force() calls for some reason
>    on the same skb, only the first one will return false.
> 
>  This now returns false even when skb had no dst, as per Erics
>  suggestion, so callers might need to check skb_dst() first before
>  skb_dst_force().
> 
> Signed-off-by: Florian Westphal <fw@...len.de>
 ...
>  Alternatively this could be routed via netfilter tree, let me
>  know your preference.

Applied and I'll queue this up for -stable, thanks Florian.