Daniel Starke

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a race condition in the status line change on dead connections in the Linux kernel's tty: n gsm component. The `gsm cleanup mux()` function cleans up the gsm by closing all DLCIs, stopping all timers, removing the virtual tty devices, and clearing the data queues. However, this procedure may cause subsequent changes to the virtual modem status lines of a DLCI, leading to a kernel panic. The fix involves proving in `gsm modem update()` that the cleanup procedure has not been started and the mux is still alive. Writing to a virtual tty is already protected by checks against the DLCI specific connection state. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a null pointer dereference in the Linux kernel. The `gsm cleanup mux()` function tries to free up virtual ttys by calling `gsm dlci release()` for each available DLCI. The `dlci put()` function is called to decrease the reference counter for the DLCI via `tty port put()`, which finally calls `gsm dlci free()`. This already clears the pointer being checked in `gsm cleanup mux()` before calling `gsm dlci release()`. The actual issue is that nothing guards `dlci put()` from being called multiple times while the tty driver was triggered but did not yet finish calling `gsm dlci free()`. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.