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

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

[Greg Kroah-Hartman]

There is a lack of much validation of frame size coming from a
netrom-based device.  While these devices are "trusted" doing some
sanity checks is good to at least keep the fuzzing tools happy when they
stumble across this ancient protocol and light up with a range of bug
reports.

Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Cc: linux-hams@vger.kernel.org
Assisted-by: gregkh_clanker_2000
Reviewed-by: Yizhe Zhuang <yizhe@darknavy.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/netrom/af_netrom.c | 6 ++++++
 net/netrom/nr_route.c  | 6 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index b816c56124ab..b605891bf86e 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -885,6 +885,9 @@ int nr_rx_frame(struct sk_buff *skb, struct net_device *dev)
 	 *	skb->data points to the netrom frame start
 	 */
 
+	if (skb->len < NR_NETWORK_LEN + NR_TRANSPORT_LEN)
+		return 0;
+
 	src  = (ax25_address *)(skb->data + 0);
 	dest = (ax25_address *)(skb->data + 7);
 
@@ -963,6 +966,9 @@ int nr_rx_frame(struct sk_buff *skb, struct net_device *dev)
 
 	sk = nr_find_listener(dest);
 
+	if (skb->len < NR_NETWORK_LEN + NR_TRANSPORT_LEN + 1 + AX25_ADDR_LEN)
+		return 0;
+
 	user = (ax25_address *)(skb->data + 21);
 
 	if (sk == NULL || sk_acceptq_is_full(sk) ||
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index 9cc29ae85b06..bf60f5682a4f 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -755,10 +755,10 @@ int nr_route_frame(struct sk_buff *skb, ax25_cb *ax25)
 	struct sk_buff *nskb, *oskb;
 
 	/*
-	 * Reject malformed packets early. Check that it contains at least 2
-	 * addresses and 1 byte more for Time-To-Live
+	 * Reject malformed packets early. Check that it contains at least
+	 * the network and transport headers (20 bytes).
 	 */
-	if (skb->len < 2 * sizeof(ax25_address) + 1)
+	if (skb->len < NR_NETWORK_LEN + NR_TRANSPORT_LEN)
 		return 0;
 
 	nr_src  = (ax25_address *)(skb->data + 0);
-- 
2.53.0

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

[Simon Horman]

On Tue, Apr 07, 2026 at 10:45:31AM +0200, Greg Kroah-Hartman wrote:
> There is a lack of much validation of frame size coming from a
> netrom-based device.  While these devices are "trusted" doing some
> sanity checks is good to at least keep the fuzzing tools happy when they
> stumble across this ancient protocol and light up with a range of bug
> reports.
> 
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Simon Horman <horms@kernel.org>
> Cc: linux-hams@vger.kernel.org
> Assisted-by: gregkh_clanker_2000
> Reviewed-by: Yizhe Zhuang <yizhe@darknavy.com>
> Cc: stable <stable@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Hi Greg 2000!

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.

Also, although I'm all for incremental enhancements,
I do suspect that similar problems exist in the call
chain of these functions.

...

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

[Jakub Kicinski]

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.

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

[Greg Kroah-Hartman]

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.

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?  :)

thanks,

greg k-h

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

[Simon Horman]

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.

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

[jj]

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.
>

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

[David Ranch]

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.
>>

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

[Dan Carpenter]

On Fri, Apr 10, 2026 at 09:38:25AM -0700, David Ranch wrote:
> 
> 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.
> 

We've had times where it felt like users weren't testing new kernels.

regards,
dan carpenter

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

[Dan Cross]

On Fri, Apr 10, 2026 at 11:49 AM jj <ve1jot@eastlink.ca> 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...

There are at least three separable issues being conflated here.

One is whether amateur radio operators are using AX.25, NET/ROM, and
ROSE.  They are; that's indisputable.

Another is whether those operators are using the implementation in the
Linux kernel.  Some are (myself included), though many fewer than are
using the protocols generally.

The third is whether preserving the implementation of these in the
kernel is the best mechanism for using those protocols on Linux-based
systems.  For that, I would argue that no, it is not.

Taking just AX.25, the current implementation has known deficiencies:
it is buggy, implements an older version of the protocol, and at best
receives nominal maintenance: notably, the newer networking tools
(`ip`, `ss`, etc) meant as replacements for `netstat`, `route`, and
`ifconfig` have not been updated to incorporate information about the
amateur radio protocols, and recent changes have left them broken for
long stretches of time.  More details are available online, such as at
https://blog.habets.se/2021/11/AX25-user-space.html

There is very little to recommend the kernel implementations, and any
unique functionality they once provided, such as IP over AX.25, can be
done via other means in userspace; e.g., one can use TAP/TUN for IP
over AX.25.

Therefore, it would be better to remove these from the kernel, and
implement them in userspace instead, or use an existing userspace
implementation (e.g., LinBPQ or similar).  Backwards compatibility
with existing Linux applications that expect to use the sockets API
with amateur radio could `LD_PRELOAD` a shim compatibility library
that simulates the current programming interface.  There is simply no
reason to preserve these in the kernel, and bluntly, the
implementation is pure drag at this point.

Note that this doesn't preclude anyone from using AX.25 et al on
Linux, or force dependency on the Internet: it just moves the
implementation of those protocols out of the kernel and into a normal
userspace program, which is arguably easier to maintain and iterate on
for the ham community, anyway.

        - Dan C.
          (KZ2X)

> 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.
> >
>

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

[Jakub Kicinski]

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:
> > 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.  
> 
> 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.

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

[Jakub Kicinski]

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.

cc: workflows, we can't be the only ones still nursing Linux 2.2 code

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

[Kuniyuki Iwashima]

From: Jakub Kicinski <kuba@kernel.org>
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 ?


> 
> cc: workflows, we can't be the only ones still nursing Linux 2.2 code

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

[Hugh Blemings]

On 11/4/2026 08:11, Kuniyuki Iwashima wrote:
> From: Jakub Kicinski <kuba@kernel.org>
> 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 hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)

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

[Craig]

> 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 :)
>

I, for one, really can't imagine pulling an entire network subsytem out 
of the kernel without any
knowledge of how/if/when it's used.  Like intercontinental radio 
networks, global email, ax.25
keyboard-to-keyboard, BBS and other emergency-communication systems 
throughout the
world.  If you're sure the Internet will never fail, I guess it makes 
sense removing all of this
since it's inconvenient to maintain.

Global AX.25 keyboard-to-keyboard on 14.105Mhz

    https://qsl.net/kb9pvh/105.html

AX.25/netrom VHF routed networks spanning from Oregon to Los Angeles.

    https://www.easymapmaker.com/map/80666c4898ec6e8fa0c35add5d03282d

Global radio email using AX.25

   https://winlink.org/RMSChannels (1,336 AX.25 email packet nodes on 
the Earth and Space)

This is all in operation by Amateur Radio ARES emergency 
protocols/technologies.  This
will not pass the headline test when it comes to Linux detractors.

Most of this is running on Raspberry Pi / Linux 24/7.

If we want to kill all these apps and somehow force them into user space,
it's akin to just switching to Windows - and flounder with the Microsoft 
folks
trying to do the same thing.


-craig
https://digipi.org/

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

[Hugh Blemings]

On 11/4/2026 08:51, Craig wrote:
>> 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 :)
>>
>
> I, for one, really can't imagine pulling an entire network subsytem 
> out of the kernel without any
> knowledge of how/if/when it's used.  Like intercontinental radio 
> networks, global email, ax.25
> keyboard-to-keyboard, BBS and other emergency-communication systems 
> throughout the
> world.  If you're sure the Internet will never fail, I guess it makes 
> sense removing all of this
> since it's inconvenient to maintain.
>
> Global AX.25 keyboard-to-keyboard on 14.105Mhz
>
>    https://qsl.net/kb9pvh/105.html
>
> AX.25/netrom VHF routed networks spanning from Oregon to Los Angeles.
>
>  https://www.easymapmaker.com/map/80666c4898ec6e8fa0c35add5d03282d
>
> Global radio email using AX.25
>
>   https://winlink.org/RMSChannels (1,336 AX.25 email packet nodes on 
> the Earth and Space)
>
> This is all in operation by Amateur Radio ARES emergency 
> protocols/technologies.  This
> will not pass the headline test when it comes to Linux detractors.
>
> Most of this is running on Raspberry Pi / Linux 24/7.
>
> If we want to kill all these apps and somehow force them into user space,
> it's akin to just switching to Windows - and flounder with the 
> Microsoft folks
> trying to do the same thing.

Your email Craig neatly encapsulates just some of the practical and 
ongoing applications of the kernel code in question - I don't think this 
is in dispute.

What's pertinent is if we as the ham/amatuer radio community can agree 
on whether in tree, out of tree modules, or a userspace device driver 
approach make the most sense.  If we are to keep code in the kernel in 
any form, we as a community need to find someone(s) that have the skills 
and bandwidth to keep the in tree code up to date.

I don't think this would be onerous and I have a couple of people in 
mind to nudge who may be happy to do so if that proves the right way 
forward.  At a pinch I could do it, but that'll mean a lot of catching 
up. But I think it reasonable that the responsibility here falls to 
folks that are closer to the code in question than the wider and 
overworked kernel maintainer community.

That said, I think Dan Cross (KZ2X) earlier email makes a pretty strong 
case for moving out of the kernel while still providing a way to have 
backward compatibility, perhaps this might be the way forward?

In any case, done well, this approach would not kill the apps or force 
anything like switching to Windows! :) Great projects like digipi would 
be able to continue with minimal changes.

I wonder if a separate thread in linux-hams makes sense to discuss the 
various longer term approaches to maintaining these capabilities - I'll 
try make time later today to kick one off - such deliberations will be 
of less interest to the broader LKML and other lists.

Cheers/73
Hugh



>
>
> -craig
> https://digipi.org/
>
>
-- 
I am slowly moving to hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)

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

[Greg KH]

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 <kuba@kernel.org>
> > 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

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

[Hugh Blemings]

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 <kuba@kernel.org>
>>> 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 hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)

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

[Greg KH]

On Sat, Apr 11, 2026 at 05:24:17PM +1000, Hugh Blemings wrote:
> 
> 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 <kuba@kernel.org>
> > > > 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.

The main "conundrum" is, is that this protocol completly trusts the
hardware to give the kernel the "correct" data.  So if you trust the
hardware to work properly, it will be fine, but as the fuzzing tools are
finding, if the data from the hardware modems is a bit out-of-spec,
"bad" things can happen.

I don't know how well controlled the data is from these devices, if it's
just a "pass through" from what they get off the "wire" or if the
devices always ensure the protocol packets are sane before passing them
off to the kernel.  That's going to be something you all with the
hardware is going to have to determine in order to keep this a working
system over time.  Especially given that this is a wireless protcol
where you "have" to trust the remote end.

thanks,

greg k-h