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