You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux
jira SECO-49
cve CVE-2023-6546
commit 3c4f833
upstream-diff we are missing several refactors of this file from
upstream and while we do not have Fixes commits in this tree, the
same bug that this addresses "grabbing the dlci pointer before taking
the mutex" still exists before those two commits.
In this case it is not that the pointer can be
NULLed while the second thread waits for the mutex but that the pointer
could be free()d in the call to gsm_dlci_release() and no longer be
valid. This could cause memory corruption as we will write to the area
pointed to.
In commit 9b9c819 ("tty: n_gsm: fix UAF in gsm_cleanup_mux"), the UAF
problem is not completely fixed. There is a race condition in
gsm_cleanup_mux(), which caused this UAF.
The UAF problem is triggered by the following race:
task[5046] task[5054]
----------------------- -----------------------
gsm_cleanup_mux();
dlci = gsm->dlci[0];
mutex_lock(&gsm->mutex);
gsm_cleanup_mux();
dlci = gsm->dlci[0]; //Didn't take the
lock
gsm_dlci_release(gsm->dlci[i]);
gsm->dlci[i] = NULL;
mutex_unlock(&gsm->mutex);
mutex_lock(&gsm->mutex);
dlci->dead = true; //UAF
Fix it by assigning values after mutex_lock().
Link: https://syzkaller.appspot.com/text?tag=CrashReport&x=176188b5a80000
Cc: stable <[email protected]>
Fixes: 9b9c819 ("tty: n_gsm: fix UAF in gsm_cleanup_mux")
Fixes: aa371e9 ("tty: n_gsm: fix restart handling via CLD command")
Signed-off-by: Yi Yang <[email protected]>
Co-developed-by: Qiumiao Zhang <[email protected]>
Signed-off-by: Qiumiao Zhang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ronnie Sahlberg <[email protected]>
0 commit comments