On 11/4/2026 15:50, Greg KH wrote:
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 :)
That's most kind Greg, thank you, have missed all you cool kids too :)
More seriously though - I'd be up for doing it, but I think there may be
others better placed than I who haven't yet realised we have this
conundrum. I'm nudging a few folks offline on this front.
I've also kicked off a thread in linux-hams to discuss some of the
broader questions raised about staying in tree, going to out of tree or
looking at userspace solutions instead.
We'll try get a cohesive picture back over next few days.
Cheers,
Hugh
--
I am slowly moving to [email protected] as my main email address.
If you're using [email protected] please update your address book accordingly.
Thank you :)
