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

I agree with John VE1JOT that amateur radio protocols such as AX25, 
NETROM, and ROSE are still very active in the Linux kernel.  This 
discussion makes me wonder how the Linux kernel community judges how 
"active" a given feature / driver / etc is being used in the real world 
before considering deprecation.  If there is an official mechanism to 
get metrics sent from users back to the kernel developer community, 
please let us know and we'll try to get you some one-off or periodic 
metrics.

--David
KI6ZHD
Avid AX.25 and NETROM packet radio on X86 and ARM-based Raspberry Pi
https://www.trinityos.com/HAM/index-ham.html


On 04/10/2026 08:12 AM, jj wrote:
> This is NOT an obsolete protocol..this is in use by amateur radio 
> operators world-wide...we use it for RF comms usually, because what 
> happens if the internet goes "down", we can still provide comms over 
> slower RF links....(plus it's a fun mode)please PLEASE do not 
> drop...and sorry for the noise...
>
> de John VE1JOT
>
> On 2026-04-10 07:28, Simon Horman wrote:
>> On Fri, Apr 10, 2026 at 07:24:36AM +0200, Greg Kroah-Hartman wrote:
>>> On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
>>>> On Thu, 9 Apr 2026 20:03:28 +0100 Simon Horman wrote:
>>>>> I expect that checking skb->len isn't sufficient here
>>>>> and pskb_may_pull needs to be used to ensure that
>>>>> the data is also available in the linear section of the skb.
>>>> Or for simplicity we could also be testing against skb_headlen()
>>>> since we don't expect any legit non-linear frames here? Dunno.
>> Sure, that's find by me if it leads to simpler code than
>> using pskb_may_pull(). Else I'd lean towards pskb_may_pull()
>> as it is a more general approach that feels worth proliferating.
>>
>>> 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?  :)
>> Deleting sounds good to me.
>> But we likely need a deprecation process.
>> In which case fixing these bugs still makes sense for the short term.
>>