linux-kernel - Re: [PATCH net v2] net: dsa: microchip: linearize skb for tail-tagging switches

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]

Message-ID: <20250513084322.22354mkqmwxtlpy7@skbuf>
Date: Tue, 13 May 2025 11:43:22 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Jakob Unterwurzacher <jakobunt@...il.com>
Cc: Woojung Huh <woojung.huh@...rochip.com>, UNGLinuxDriver@...rochip.com,
	Andrew Lunn <andrew@...n.ch>,
	"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>, Marek Vasut <marex@...x.de>,
	Tristram Ha <Tristram.Ha@...rochip.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	jakob.unterwurzacher@...rry.de, stable@...r.kernel.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] net: dsa: microchip: linearize skb for
 tail-tagging switches

On Mon, May 12, 2025 at 04:44:18PM +0200, Jakob Unterwurzacher wrote:
> The pointer arithmentic for accessing the tail tag only works
> for linear skbs.
> 
> For nonlinear skbs, it reads uninitialized memory inside the
> skb headroom, essentially randomizing the tag. I have observed
> it gets set to 6 most of the time.
> 
> Example where ksz9477_rcv thinks that the packet from port 1 comes from port 6
> (which does not exist for the ksz9896 that's in use), dropping the packet.
> Debug prints added by me (not included in this patch):
> 
> 	[  256.645337] ksz9477_rcv:323 tag0=6
> 	[  256.645349] skb len=47 headroom=78 headlen=0 tailroom=0
> 	               mac=(64,14) mac_len=14 net=(78,0) trans=78
> 	               shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0))
> 	               csum(0x0 start=0 offset=0 ip_summed=0 complete_sw=0 valid=0 level=0)
> 	               hash(0x0 sw=0 l4=0) proto=0x00f8 pkttype=1 iif=3
> 	               priority=0x0 mark=0x0 alloc_cpu=0 vlan_all=0x0
> 	               encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)
> 	[  256.645377] dev name=end1 feat=0x0002e10200114bb3
> 	[  256.645386] skb headroom: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 	[  256.645395] skb headroom: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 	[  256.645403] skb headroom: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 	[  256.645411] skb headroom: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 	[  256.645420] skb headroom: 00000040: ff ff ff ff ff ff 00 1c 19 f2 e2 db 08 06
> 	[  256.645428] skb frag:     00000000: 00 01 08 00 06 04 00 01 00 1c 19 f2 e2 db 0a 02
> 	[  256.645436] skb frag:     00000010: 00 83 00 00 00 00 00 00 0a 02 a0 2f 00 00 00 00
> 	[  256.645444] skb frag:     00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
> 	[  256.645452] ksz_common_rcv:92 dsa_conduit_find_user returned NULL
> 
> Call skb_linearize before trying to access the tag.
> 
> This patch fixes ksz9477_rcv which is used by the ksz9896 I have at
> hand, and also applies the same fix to ksz8795_rcv which seems to have
> the same problem.
> 
> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@...rry.de>
> Cc: stable@...r.kernel.org
> Fixes: 016e43a26bab ("net: dsa: ksz: Add KSZ8795 tag code")
> Fixes: 8b8010fb7876 ("dsa: add support for Microchip KSZ tail tagging)
> ---

One of the blamed commits appeared in v4.13 and the other in v5.4.
I wondered whether separate patches should have been written, so that the
bug fix for the older commit could be independently backported further.
But then I looked at https://www.kernel.org/ and it seems that the
oldest supported LTS branch is 5.4, so that's irrelevant.

Reviewed-by: Vladimir Oltean <olteanv@...il.com>