[14:37] <brlin> Hello, I would like to ask whether the CVE-2023-6546 vulnerability has been dealt with in the Ubuntu kernels?  I unable to locate notices about it in the USN.
[14:38] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[14:38]  * brlin Good bot (pats).
[14:39] <brlin> Additional info: https://github.com/YuriiCrimson/ExploitGSM (There seems to be a conflict of who is the original author of the PoC, though it's not really our businesses.)
[14:45] <tomreyn> https://ubuntu.com/security/CVE-2023-6546
[14:45] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[14:47] <tomreyn> (i'm not sure that the exploit you posted is mitigated by the existing fix.)
[14:48] <tomreyn> and i'm not speaking for ubuntu or the security team
[14:54] <brlin> tomreyn: Thanks for the information!  I'll check it out.
[15:09] <sbeattie> brlin: assuming that CVE-2023-6546 is the fix for what is being exploited above, yes, it has been addressed in ubuntu kernels
[15:09] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[15:10] <brlin> sbeattie: Thanks for the information mOwOm.
[15:13] <sbeattie> brlin: oh, boo, the initial fix for CVE-2023-6546 got reverted upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29346e217b8ab8a52889b88f00b268278d6b7668
[15:13] -ubottu:#ubuntu-security- Commit 29346e2 in kernel/git/torvalds/linux.git "Revert 'tty: n_gsm: fix UAF in gsm_cleanup_mux'"
[15:13] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[15:14] <brlin> sbeattie: That's...interesting.
[15:16] <brlin> Though the upstream should have a following patch to fix the vulnerability, right?
[15:19] <sbeattie> brlin: sorry, I'm confusing myself by doing this without enough coffee.
[15:20] <sbeattie> brlin: the fix for CVE-2023-6546, 3c4f8333b582 ("tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux"), was not reverted.
[15:20] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[15:21] <brlin> sbeattie: No worries.  Thanks for the confirmation, BTW.
[15:22] <sbeattie> but that commit references fixing 9b9c8195f3f0 ("tty: n_gsm: fix UAF in gsm_cleanup_mux") which is also what got reverted in 29346e217b8ab8a52889b88f00b268278d6b7668 linked above
[15:23]  * brlin Probably will try the PoC on a fresh cloud VM just to see if it works.
[15:23] <sbeattie> so while I think CVE-2023-6546 in isolation may be "fixed" there are still other UAFs in the n_gsm.c code, the root cause explained by the revert commit
[15:23] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[15:24] <brlin> Thanks for the analysis.
[15:24] <sbeattie> bah, the bot needs a silence cache, to not report the same CVE id in the space of a few minutes.
[15:24]  * brlin lmao
[15:26] <sbeattie> The english writeup at https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html has a screenshot at the end of running the exploit on ubuntu against a 6.5.0-25 ubuntu kernel; if not doctored (I don't think it is, but you never know), that kernel has the commit  3c4f8333b582 ("tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux"
[15:33] <sbeattie> looking through the commit history for n_gsm.c, I'm not seeing anything that would fix that, but that's based on a quick perusal.
[15:36] <sbeattie> Thanks for raising the issue.
[15:55] <brlin> sbeattie: No problem.
[18:27] <brlin> sbeattie: I'd like to inform you that I am able to reproduce the vulnerability on a GCP Compute Engine instance running `6.5.0-27-generic` Ubuntu kernel(the GCP kernel doesn't seemed to be vulnerable as the n_gsm module doesn't seem to be built).  The first invocation of the PoC code stuck at the `waiting setconf dlci thread` stage, but the second invocation get me a root shell.  This is reproduced using the 2e87080 revision of the PoC.
[18:29]  * brlin Thinks as the PoC is already in the wild, there's probably no reason to discuss it in private, but do inform me if I'm wrong.
[18:33] <sbeattie> brlin: thanks for reproducing, I agree, the writeups are public, so no sense trying to keep it private
[18:34] <brlin> Note that the OffsetGenerater program in the PoC code must first be run (as root, but possibly can be done in another host with the same kernel) to generate the data that needs to be inserted in the `kernels_offsets` array of the PoC code(~line 370).  I'll leave the matter to you :D.
[19:32] <sbeattie> brlin: FYI https://lore.kernel.org/stable/2024041054-asleep-replace-96e8@gregkh/T/#m3a8ce43359ad57e447faa4db6ecf4f4c1b60c498
[19:41] <brlin> sbeattie: Thanks for the information!