Re: [PATCH] tty: n_gsm: bound the EA scan in gsm_control_rls()

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sun, Jun 07, 2026 at 07:09:06AM -0400, Michael Bommarito wrote:
> On Sun, Jun 7, 2026 at 2:38 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > While it's fun to throw LLMs at this codebase, how was this actually
> > tested?  there are loads of documented "problems" with this file, but in
> > the real world, with real devices, it works fine so without testing of
> > the code with those devices, we have to be careful with changing
> > anything here.
> 
> Understood.  A few different notes for you to consider on this one:
> 
> 1. This is almost certainly the continuation / completion of
> 669609cea1d29, where two other sites were similarly addressed.  I
> think Daniel could answer if there was a reason why he didn't include
> this spot, but there's no evidence in the commit log or code comments
> otherwise.

It was perhaps missed, or not actually needed?  Again, how was this
tested?

> 2. The backport situation on 67c37756898a5 (the CAP_NET_ADMIN gate)
> looks complicated because it wasn't originally stable tagged and
> didn't get actioned by vendors for awhile, so I think reachability for
> unprivileged chaining in attacks is still high.

Distros/vendors know all about this line dicipline and they enable it at
their own risk.  There should not be any that has it enabled for normal
users, and I would not enabling it at all except for systems that
actually has this hardware.

> 3. I'm normally running tests on UML or qemu for every patch I submit.
> Sometimes, the AI assistance tag is more about the testing side of the
> patch than anything else.

That's fine, but where is the test?

> For example, for this patch, here's what Claude logged for the
> regression testing:
> 
> <CLAUDE>
>   repro/loopback.c stands up two real N_GSM0710 line disciplines in
> one UML kernel, wired back to back through a userspace byte relay — so
> the kernel runs both the
>   initiator and responder TS 27.010 state machines (not a
> userspace-faked peer like trigger.c). Phases:
> 
>   - A — DLCI0 + DLCI1 SABM/UA handshake (kernel both ends)
>   - B — bidirectional gsmtty data, byte-exact (PING/PONG)
>   - C — drop/raise DTR/RTS → real MSC frames → peer modem lines track
> them (before=0x0 low=0x40 high=0x166)
>   - D — inject a valid CMD_RLS (clen=2) on DLCI0 → accepted by the
> patched gsm_control_rls, mux keeps carrying data
>   - E — clean teardown
> </CLAUDE>

Adding tests like this to the tree would be great.

> 4.  Relatedly, I think it would be helpful for someone (Willy again?)
> to improve the guidance for AI assisted testing and establish some
> standards for documentation.

Why not submit it yourself?

> Because most of the kernel doesn't have
> established KUnit setups and dumping all this info is frowned upon in
> commit logs or notes, it seems like there is a tension between
> "showing your work" and sticking to general convention.

Add the test!  We'll gladly take them, that would make it even easier to
prove changes work, AND prevent regressions in the future.

thanks,

greg k-h