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). Changes since v1: - Fix the UAF by reference-pinning instead of a NULL check in the handlers; no gsm->mutex in the data path (Greg, Daniel). - Pin every DLCI the dispatch touches, not just the addressed one: MSC/RLS/PN operate on gsm->dlci[k] named in the payload. - Add a base selftest (patch 2), as Greg asked. Verification (KASAN, panic_on_warn=1): the originally reported splat is the gsm_control_reply() / CMD_TEST path (see the Link in patch 1). A reproducer targeting the MSC handler crashes the unpatched kernel and survives 270 race rounds on v2. The selftest passes on both the clean and patched kernel (pass:3 fail:0 skip:0). Weiming Shi (2): tty: n_gsm: fix use-after-free in gsm_queue() control frame dispatch selftests: tty: add base regression test for n_gsm line discipline drivers/tty/n_gsm.c | 105 +++++- tools/testing/selftests/tty/.gitignore | 1 + tools/testing/selftests/tty/Makefile | 2 +- tools/testing/selftests/tty/config | 1 + tools/testing/selftests/tty/tty_n_gsm_test.c | 344 +++++++++++++++++++ 5 files changed, 443 insertions(+), 10 deletions(-) create mode 100644 tools/testing/selftests/tty/tty_n_gsm_test.c -- 2.43.0
