Thanks for your work, Hugh. -73 de Chris KQ6UP
On Sat, Apr 11, 2026 at 7:33 PM Hugh Blemings <[email protected]> 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 <[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 ? > >>> 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
