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

[Chris Maness <christopher.maness@gmail.com>]

Thanks for your work, Hugh.

-73 de Chris KQ6UP

On Sat, Apr 11, 2026 at 7:33 PM Hugh Blemings <hugh@blemings.org> wrote:
>
>
> On 11/4/2026 18:58, Greg KH wrote:
> > 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 for the thoughts Greg - and ya, I guess on balance I come back to
> being generally skeptical of both hardware and software to Do The Right
> Thing (TM)
>
> So bounds checking and the like seems prudent irrespective of whether
> the kernel is getting the data from real hardware, software modems etc.
>
> I've done some initial digging around that confirms my suspicion that
> this in kernel code remains quite widely used, if somewhat out of view.
> Accordingly I lean then towards working to get these various mitigations
> in place with some revised patches etc. as needed and into the main tree.
>
> Once this done I think that'll give me a good sense of whether I or
> someone else is well positioned to keep the code maintained longer term
> and thus justify it remaining in tree or not.
>
> More to follow once I finish remembering this kernel thing!
>
> Cheers,
> Hugh
>
>
>
>


-- 
Thanks,
Chris Maness