YuriiCrimson
Who is the original author?
https://github.com/jmpe4x/GSM_Linux_Kernel_LPE_Nday_Exploit/tree/main
This was pushed 3 weeks ago and the exploit is bar from a few lines identical. The writeup (after translation to english) is also a close copy of https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html.
This was pushed 3 weeks ago and the exploit is bar from a few lines identical. The writeup (after translation to english) is also a close copy of https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html.
Is this fixed in distros already?
This was pushed 3 weeks ago and the exploit is bar from a few lines identical. The writeup (after translation to english) is also a close copy of https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html.
Is this fixed in distros already?
It is fixed in the kernel: https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3
The changelog for 6.5.0-27 seems to contain the fix.
This was pushed 3 weeks ago and the exploit is bar from a few lines identical. The writeup (after translation to english) is also a close copy of https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html.
Is this fixed in distros already?
It is fixed in the kernel: https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3
The changelog for 6.5.0-27 seems to contain the fix.
It is not fix this vulnerability
It is fixed in the kernel: torvalds/linux@3c4f833 The changelog for 6.5.0-27 seems to contain the fix.
It is not fix this vulnerability
The burden of proof lies on the person trying to proof something, huh?
It is fixed in the kernel: torvalds/linux@3c4f833 The changelog for 6.5.0-27 seems to contain the fix.
It is not fix this vulnerability
The burden of proof lies on the person trying to proof something, huh?
Mmm my exploit use race condition in gsm_dlci_config not in gsm_cleanup_mux
It is fixed in the kernel: torvalds/linux@3c4f833
The changelog for 6.5.0-27 seems to contain the fix.
That commit went to v6.5, the entire line shouldn't be affected. Exploit seems to work on 6.5.* kernels. Different CVE?
It is fixed in the kernel: torvalds/linux@3c4f833
The changelog for 6.5.0-27 seems to contain the fix.
That commit went to v6.5, the entire line shouldn't be affected. Exploit seems to work on 6.5.* kernels. Different CVE?
My exploit use race condition in gsm dlci config. Not stupid gsm cleanup mux
The article in English seems to be a translation from the writeup in Ukrainian published in this repository. You can deduct it by comparing the language in the two.
Here is one of the biggest giveaways: "черга очікувань" (waiting queue) is translated as "queue of expectations", because in Ukrainian to wait and to expect are the same word.
Will including this https://lore.kernel.org/stable/2024041054-asleep-replace-96e8@gregkh/T/#t in the kernel branches in the future address the new issue properly?
How much different is the technique used in exploit 5.15-6.5 from the other one? Will you make a writeup on the former?
How much different is the technique used in exploit 5.15-6.5 from the other one? Will you make a writeup on the former?
Exploit for 5.15-6.5 it is another zero day and i am not make for this exploit writeup.
How much different is the technique used in exploit 5.15-6.5 from the other one? Will you make a writeup on the former?
Exploit for 5.15-6.5 it is another zero day and i am not make for this exploit writeup.
Thanks, mate. I will certainly dive into the source code? but as far as I understand it also relates to some flaw in n_gsm module.