netdev - Re: [PATCH net v5] net: stmmac: Prevent DSA tags from breaking COE

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: Tue, 16 Jan 2024 07:23:00 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Romain Gantois <romain.gantois@...tlin.com>
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>, Jose Abreu
 <joabreu@...opsys.com>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Maxime
 Coquelin <mcoquelin.stm32@...il.com>, Miquel Raynal
 <miquel.raynal@...tlin.com>, Maxime Chevallier
 <maxime.chevallier@...tlin.com>, Sylvain Girard <sylvain.girard@...com>,
 Pascal EBERHARD <pascal.eberhard@...com>, Richard Tresidder
 <rtresidd@...ctromag.com.au>, Linus Walleij <linus.walleij@...aro.org>,
 Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>, Thomas
 Petazzoni <thomas.petazzoni@...tlin.com>, netdev@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, stable@...r.kernel.org, Vladimir
 Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net v5] net: stmmac: Prevent DSA tags from breaking COE

On Tue, 16 Jan 2024 13:14:15 +0100 (CET) Romain Gantois wrote:
> > > @@ -4997,7 +5020,7 @@ static void stmmac_dispatch_skb_zc(struct stmmac_priv *priv, u32 queue,
> > >  	stmmac_rx_vlan(priv->dev, skb);
> > >  	skb->protocol = eth_type_trans(skb, priv->dev);
> > >  
> > > -	if (unlikely(!coe))
> > > +	if (unlikely(!coe) || !stmmac_has_ip_ethertype(skb))  
> > 
> > The lack of Rx side COE checking in this driver is kinda crazy.
> > Looking at enh_desc_coe_rdes0() it seems like RDES0_FRAME_TYPE
> > may be the indication we need here?   
> 
> I don't think that RDES0_FRAME_TYPE would be enough, at least not on its own. 
> That bit is set by checking the length/ethertype field to see if is an 
> Ethernet II frame or an IEEE802.3 frame. But even Ethernet II frames with non-IP 
> ethertypes will not be checksummed. Also protocols with a non-fixed ethertype 
> field such as DSA_TAG_PROTO could trigger the bit, or not, depending on what 
> they put in the DSA tag.

Hm, the comment in enh_desc_coe_rdes0() says:

	/* bits 5 7 0 | Frame status
	 * ----------------------------------------------------------
	 *      0 0 0 | IEEE 802.3 Type frame (length < 1536 octects)
	 *      1 0 0 | IPv4/6 No CSUM errorS.
	 *      1 0 1 | IPv4/6 CSUM PAYLOAD error
	 *      1 1 0 | IPv4/6 CSUM IP HR error
	 *      1 1 1 | IPv4/6 IP PAYLOAD AND HEADER errorS
	 *      0 0 1 | IPv4/6 unsupported IP PAYLOAD
	 *      0 1 1 | COE bypassed.. no IPv4/6 frame
	 *      0 1 0 | Reserved.
	 */

which makes it sound like bit 5 will not be set for a Ethernet II frame
with unsupported IP payload, or not an IP frame. Does the bit mean other
things in different descriptor formats?