netdev - Re: [PATCH net] net: hsr: avoid potential out-of-bound access in fill_frame

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]

Message-ID: <Z4o_UC0HweBHJ_cw@PC-LX-SteWu>
Date: Fri, 17 Jan 2025 12:30:24 +0100
From: Stephan Wurm <stephan.wurm@...berle.de>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, eric.dumazet@...il.com,
	syzbot+671e2853f9851d039551@...kaller.appspotmail.com,
	WingMan Kwok <w-kwok2@...com>,
	Murali Karicheri <m-karicheri2@...com>,
	MD Danish Anwar <danishanwar@...com>, Jiri Pirko <jiri@...dia.com>,
	George McCollister <george.mccollister@...il.com>
Subject: Re: [PATCH net] net: hsr: avoid potential out-of-bound access in
 fill_frame_info()

Hello Eric,

Am 26. Nov 14:43 hat Eric Dumazet geschrieben:
> syzbot is able to feed a packet with 14 bytes, pretending
> it is a vlan one.
>
> Since fill_frame_info() is relying on skb->mac_len already,
> extend the check to cover this case.
thanks for addressing this szybot finding.

Unfortunately, this seems to cause issues with VLAN tagged frames being
dropped from a PRP interface.

My setup consists of a custom embedded system equipped with v6.6 kernel,
recently updated from v6.6.62 to v6.6.69. In order to gain support for
VLAN tagged messages on top of PRP, I have applied first patch of the
series (see msgid 20241106091710.3308519-2-danishanwar@...com) that is
currently integrated with v6.13.

Now I want to send GOOSE messages (L2 broadcast messages with VLAN
header, including id=0 and QoS information) via the PRP interface.
With v6.6.62 this works as expected, with v6.6.69 the functionality
stopped again, with all VLAN-tagged frames being dropped from the PRP
interface.

By reverting this fix locally, I was able to restore the desired
functionality. But I do not iyet understand, why this fix breaks
sending of VLAN tagged frames in general.

Do you already know about this side effect?
Can you guide me to narrow down this issue?

Best regards
Stephan