netdev - Re: [PATCH v3 net-next 00/12] Generic TX reallocation for DSA

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 2 Nov 2020 17:43:08 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     netdev@...r.kernel.org, andrew@...n.ch, f.fainelli@...il.com,
        vivien.didelot@...il.com, Christian Eggers <ceggers@...i.de>,
        Kurt Kanzenbach <kurt@...utronix.de>
Subject: Re: [PATCH v3 net-next 00/12] Generic TX reallocation for DSA

On Sun,  1 Nov 2020 21:16:08 +0200 Vladimir Oltean wrote:
> Christian has reported buggy usage of skb_put() in tag_ksz.c, which is
> only triggerable in real life using his not-yet-published patches for
> IEEE 1588 timestamping on Micrel KSZ switches.
> 
> The concrete problem there is that the driver can end up calling
> skb_put() and exceed the end of the skb data area, because even though
> it had reallocated the frame once before, it hadn't reallocated it large
> enough. Christian explained it in more detail here:
> 
> https://lore.kernel.org/netdev/20201014161719.30289-1-ceggers@arri.de/
> https://lore.kernel.org/netdev/20201016200226.23994-1-ceggers@arri.de/
> 
> But actually there's a bigger problem, which is that some taggers which
> get more rarely tested tend to do some shenanigans which are uncaught
> for the longest time, and in the meanwhile, their code gets copy-pasted
> into other taggers, creating a mess. For example, the tail tagging
> driver for Marvell 88E6060 currently reallocates _every_single_frame_ on
> TX. Is that an obvious indication that nobody is using it? Sure. Is it a
> good model to follow when developing a new tail tagging driver? No.
> 
> DSA has all the information it needs in order to simplify the job of a
> tagger on TX. It knows whether it's a normal or a tail tagger, and what
> is the protocol overhead it incurs. So this series performs the
> reallocation centrally.

Applied, thank you!