On Sat, Apr 11, 2026 at 08:25:19AM +1000, Hugh Blemings wrote: > > On 11/4/2026 08:11, Kuniyuki Iwashima wrote: > > 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 ? > > > > > If the main concern here is ongoing maintenance of these Ham Radio related > protocols/drivers, can we pause for a moment on anything as dramatic as > removing from the tree entirely ?
Sure, but: > There is a good cohort of capable kernel folks that either are or were ham > radio operators who I believe, upon realising that things have got to this > point, will be happy to redouble efforts to ensure this code maintained and > tested to a satisfactory standard. We need this code to be maintained, because as is being shown, there are reported problems with it that will affect these devices/networks that you all are using. So all we need is a maintainer for this to be able to take reports that we get and fix things up as needed. I know you have that experience, want to come back to kernel development, we've missed you :) thanks, greg k-h
