Re: [PATCH v2 0/2] tty: n_gsm: fix gsm_queue() UAF and add a base regression test

["Weiming Shi" <bestswngs@gmail.com>]

On Wed Jun 17, 2026 at 9:24 AM CST, Greg Kroah-Hartman wrote:
> On Tue, Jun 16, 2026 at 10:32:38AM -0700, Weiming Shi wrote:
>> The receive worker walks gsm->dlci[] without gsm->mutex while a
>> concurrent GSMIOC_SETCONF -> gsm_cleanup_mux() frees the DLCIs, so the
>> control handlers can dereference a freed gsm_dlci. v1's NULL check only
>> narrowed the window; v2 fixes the use-after-free itself.
>> 
>> The fix pins each DLCI the dispatch dereferences with its existing
>> tty_port reference (option 2), so the data path stays lock-free. See the
>> patch 1 commit message for details, including why the late destructor
>> uses cmpxchg() so it cannot wipe a re-created mux (Daniel's teardown
>> concern).
>
> Cool, but wow, that's complex for something that will never actually
> happen in a real device :)
>
> So do we want to add that complexity?  if so, why?
>
> Ideally Daniel can verfiy this change is ok as they are the only known
> user here.
>
> And thanks for the test patch, but that's just a functional test, while
> great to have, and not one that can actually mimic a real device with
> its timing constraints, right?
>
> thanks,
>
> greg k-h

Hi,

The complexity is just the cmpxchg() in gsm_dlci_free(). The actual UAF fix
is only the tty_port pin (dlci_get/put) around the dispatch, which doesn't 
touch any fast path. The cmpxchg() only guards the teardown+recreate case 
Daniel mentioned, and isn't needed for the UAF.

So should I drop it and respin a v3 with the pin only? The use-after-free 
is fully fixed either way.

Daniel, does the pin approach look right to you?

And yes, the test is functional only (pty bring-up/teardown, no timing). 
It's the base regression test, not a race reproducer.

Thanks,
Weiming Shi