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

[Michael Bommarito]

On Sun, Jun 7, 2026 at 2:38 AM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> 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.


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.


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.

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>


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


P.S. I know it's somewhat contentious, but maybe one of the best use
cases for AI would be helping maintainers add or improve KUnit or
out-of-kernel test frameworks.  I have dozens of orphaned tests or
harnesses across the kernel now and would be happy to contribute them
or use my tokens for the cause.

Thanks,
Mike