From: Jakub Kicinski <[email protected]> Date: Fri, 10 Apr 2026 14:54:48 -0700 > On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote: > > On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote: > > > On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote: > > > > Or for simplicity we could also be testing against skb_headlen() > > > > since we don't expect any legit non-linear frames here? Dunno. > > > > > > I'll be glad to change this either way, your call. Given that this is > > > an obsolete protocol that seems to only be a target for drive-by fuzzers > > > to attack, whatever the simplest thing to do to quiet them up I'll be > > > glad to implement. > > > > > > Or can we just delete this stuff entirely? :) > > > > Yes. > > > > My thinking is to delete hamradio, nfc, atm, caif.. [more to come] > > Create GH repos which provide them as OOT modules. > > Hopefully we can convince any existing users to switch to that. > > > > The only thing stopping me is the concern that this is just the softest > > target and the LLMs will find something else to focus on which we can't > > delete. I suspect any PCIe driver can be flooded with "aren't you > > trusting the HW to provide valid responses here?" bullshit. > > > > But hey, let's try. I'll post a patch nuking all of hamradio later > > today. > > Well, either we "expunge" this code to OOT repos, or we mark it > as broken and tell everyone that we don't take security fixes > for anything that depends on BROKEN. I'd personally rather expunge.
+1 for "expunge" to prevent LLM-based patch flood. IIRC, we did that recently for one driver only used by OpenWRT ? > > cc: workflows, we can't be the only ones still nursing Linux 2.2 code
