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
