Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Hugh Blemings
Date: Fri Apr 10 2026 - 18:34:14 EST
On 11/4/2026 08:11, Kuniyuki Iwashima wrote:
From: Jakub Kicinski <kuba@xxxxxxxxxx>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 ?
Date: Fri, 10 Apr 2026 14:54:48 -0700
On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:+1 for "expunge" to prevent LLM-based patch flood.
On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:Well, either we "expunge" this code to OOT repos, or we mark it
On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:Yes.
Or for simplicity we could also be testing against skb_headlen()I'll be glad to change this either way, your call. Given that this is
since we don't expect any legit non-linear frames here? Dunno.
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? :)
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.
as broken and tell everyone that we don't take security fixes
for anything that depends on BROKEN. I'd personally rather expunge.
IIRC, we did that recently for one driver only used by OpenWRT ?
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.
Or, alternatively, as a technical community it may be that the Ham Radio interested folks conclude that out of tree or user space solutions are a better way forward as others have proposed.
Give us a few days, please, for the word to be put around that we need to pull ourselves together a bit as a technical group :)
Cheers/73
Hugh
VK3YYZ/AD5RV/Lapsed Kernel Maintainer... ;)
cc: workflows, we can't be the only ones still nursing Linux 2.2 code
--
I am slowly moving to hugh@xxxxxxxxxxxxxx as my main email address.
If you're using hugh@xxxxxxxxxxxx please update your address book accordingly.
Thank you :)