Re: [PATCH net] netrom: do some basic forms of validation on incoming frames

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 ?

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 [email protected] as my main email address.
If you're using [email protected] please update your address book accordingly.
Thank you :)