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
