netdev - Re: [PATCH net 2/3] net: dsa: Remove dangerous DSA_SKB

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]

Date:   Sun, 12 May 2019 04:39:01 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     f.fainelli@...il.com, vivien.didelot@...il.com,
        davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net 2/3] net: dsa: Remove dangerous DSA_SKB_CLONE() macro

On Sat, May 11, 2019 at 11:14:46PM +0300, Vladimir Oltean wrote:
> This does not cause any bug now because it has no users, but its body
> contains two pointer definitions within a code block:
> 
> 		struct sk_buff *clone = _clone;	\
> 		struct sk_buff *skb = _skb;	\
> 
> When calling the macro as DSA_SKB_CLONE(clone, skb), these variables
> would obscure the arguments that the macro was called with, and the
> initializers would be a no-op instead of doing their job (undefined
> behavior, by the way, but GCC nicely puts NULL pointers instead).
> 
> So simply remove this broken macro and leave users to simply call
> "DSA_SKB_CB(skb)->clone = clone" by hand when needed.
> 
> There is one functional difference when doing what I just suggested
> above: the control block won't be transferred from the original skb into
> the clone. Since there's no foreseen need for the control block in the
> clone ATM, this is ok.
> 
> Fixes: b68b0dd0fb2d ("net: dsa: Keep private info in the skb->cb")
> Signed-off-by: Vladimir Oltean <olteanv@...il.com>

If it has no users, it should not of been merged.

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew