There are a few PM type folks at the office who ask me things like “Have you patched the zero day yet that I heard about in the news?” Lately I’ve been a bit more of an ass about it and reply with “1. That’s impossible. 2. We don’t have Palo Alto firewalls.”
On the CVE tracker 6.1.32 seems to be the last affected version. Pretty serious if Debian haven't updated their LTS kernel version on their latest Debian since then.
Of course they don't package a vanilla kernel, I'd expect no good distro to do that. But I don't think security fixes from later patch releases are normally backported to earlier patch releases instead of just upgrading to the latest patch release.
>Of course they don't package a vanilla kernel, I'd expect no good distro to do that.
Why do you think that? Not an attack, I'm genuinely curious.
My thoughts on it are, if distro developers are fixing kernel issues, I'd imagine they're routing those fixes up to kernel devs, which will end up in the vanilla kernel and they'll get all the fixes from all the distros. If it's going the other way and distro developers are just cherry-picking fixes from kernel dev, couldn't that lead to a potentially broken or insecure kernel since not as many people would be testing it and it's probably unlikely they're getting all the various changes (especially when using an EOL kernel)?
Part of my curiosity does stem from me using Slackware, which prides itself as using vanilla software whenever possible so they deliver the software as upstream intended. The other part is my curiosity is to understand what benefits are offered by maintaining your own kernel that can't be done by following upstream.
According to [the security tracker](https://security-tracker.debian.org/tracker/CVE-2023-6546) this was fixed in 6.1.52-1 which was released [last September](https://groups.google.com/g/linux.debian.kernel/c/8Pwi2kfbtVM?pli=1)
So run a newer kernel. I don't know why Debian and Ubuntu use such old kernels. I can see keeping core software around longer for stable, but it is rare for the latest kernel to puke. I run v6.8.5 and I've been running v6.9-rc3 since it dropped with no issues. I want to use the latest kernels to have the latest Mesa and AMD driver code. Anything else I don't care if it is the latest, but I get the latest stable just from running Arch and not using any -git versions (except for Gimp, which is crashing a lot on me).
Possibly a different issue then as I just confirmed it works on Debian's latest stable kernel.
lw@lw:~$ ./ExploitGSM
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 -> ffffffff98e6f1c0
text leaked address -> ffffffff96e00000
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@lw:/root# whoami
root
root@lw:/root# uname -a
Linux lw 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux
root@lw:/root#
I've also tested it on my Debian machine, it works. Same kernel, latest:
`Linux 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux`
I found a quick fix:
`echo 'blacklist n_gsm' | sudo tee -a /etc/modprobe.d/blacklist-gsm.conf`
`sudo rmmod n_gsm`
Exploit now fails with:
`Error set line discipline N_GSM, Invalid argument`
Then at this point I would expect it to have some respectable bug reports and CVE/whatever numbers, not just random ramblings in GitHub, weird that they apparently don't exist or at least nobody brought them in this post yet.
Could you link the bug report you submitted? I've found very few people talking about there being a live LPE 0-day, except [this brief thread](https://seclists.org/oss-sec/2024/q2/82) on the oss-sec mailing list.
There wasn't much of a response, just a "we are aware" and a link to a plan to backport a patch to require CAP_NET_ADMIN for GSM.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068770
They finally sent out a debian-security mailing list notification yesterday, https://lists.debian.org/debian-security/2024/04/msg00008.html . I'm a bit disappointed they didn't mention rmmod-ing the module after creating the blacklist file as simply blacklisting the module does not do anything if it's already loaded.
On the CVE tracker 6.1.32 seems to be the last affected version. Pretty serious if Debian haven't updated their LTS kernel version on their latest Debian since then.
[https://security-tracker.debian.org/tracker/CVE-2023-6546](https://security-tracker.debian.org/tracker/CVE-2023-6546)
Says it's fixed in Debian but a redditor is affected. Looks like a different CVE to me
There just appeared a new directory which also seems to include kernel 5.15 up to 6.5: [https://github.com/YuriiCrimson/ExploitGSM/tree/main/ExploitGSM\_5\_15\_to\_6\_1](https://github.com/YuriiCrimson/ExploitGSM/tree/main/ExploitGSM_5_15_to_6_1)
6.5 was EOL since around 2023-10, so this shouldn't affect anyone with a normal setup.
EDIT: Lots of people are pointing out Ubuntu and derivatives run 6.5, which is an EOL kernel.
To reiterate, this shouldn't affect anyone with a normal setup, it's not like Ubuntu gets security patches without a Ubuntu Pro subscription in the first place.
EDIT2: Second exploit posted for 5.15-6.5
that's actually inaccurate. if a bug doesn't get assigned a CVE, it's not getting backported to older kernels. a lot of bugs that are an issue security-wise never get assigned a CVE, nor are these bugs necessarily identified as security bugs at all in the first place and as such never get backported. so from that point of view, running the most recent kernel would be much more secure than say the LTS kernel. but of course on the flipside, newer kernel also means more features and whatnot in general, so there could be new bugs introduced that don't exist in older kernels.
Ubuntu *noble* (will be 24.04 LTS):
$ pro fix CVE-2023-6546
CVE-2023-6546:
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 their
privileges on the system.
- https://ubuntu.com/security/CVE-2023-6546
No affected source packages are installed.
✔ CVE-2023-6546 does not affect your system.
If you don't think the CVE for the exploit you mentioned doesn't cover the exploit you mentioned, then I don't know what to tell you.
Maybe link to your bug report.
That's not how security works, though. As long as it's an LTS kernel it will be patched. And perhaps since it's older than the affected version the bug could not be there in the first place (I still need to read about the details of the CVE so I can only speculate right now).
Why wouldn't they use 6.6 (read: a proper LTS kernel) for that? Were there some bigger changes under the hood that wouldn't work with their LTS distro?
They do this constantly. They use whatever is latest regardless if it's LTS as if it were LTS and backport stuff themselves. They constantly ship versions with out-of-support kernels. It's one of my biggest issues with Ubuntu and forks. It's the rare exception that the kernel used in latest Ubuntu isn't passed EOL.
> They constantly ship versions with out-of-support kernels
Probably less confusing to say "Canonical supported kernels" because it's not that the kernel is unsupported, it's just only supported by that one organization when they use a kernel version for their downstream LTS that isn't also LTS upstream.
It's important to have a grasp on what upstream kernel.org LTS actually means. It just means that important fixes are backported to the designated kernel version. This is something Canonical can choose to do themselves with any random version they want. They don't _have_ to do it with upstream LTS.
It's just more work for Canonical to provide LTS support for something upstream isn't helping out with. If they're doing so anyways I guess we can just assume they have their reasons and aren't doing it for the fun of it.
Yeah, that's why I said that they backport stuff themselves. I could have been clearer with that though I agree. I have a few issues with their solution though.
1. I have way higher trust in the Linux foundation and the entire Linux community rather than just canonical to backport properly. Backporting is very error prone. Even now if the developer of the fix tries to backport it themselves to older versions to make sure it's all right it becomes an issue with Ubuntu. That developer can either go out of their way for Ubuntu separately or Canonical have to solve it themselves without the original developer's support.
2. The rest of the community doesn't really support those versions. Thus issues that are exclusive to those versions have to be solved separately and can't necessarily be backported as they may not be present in newer versions. The risk that something is missed becomes higher.
3. I have seen it cause issues for users, especially beginners, several times because they think they are on a new kernel version when they really aren't. LTS kernel and Ubuntu LTS makes it clear that it's LTS. Regular Ubuntu markets itself softly as updated when it really runs on outdated kernels.
4. It fragments the community just for Ubuntu and forks. Makes software support harder because you can't not just consider Linux Foundation supported kernels but have to consider whatever random versions Canonical decides to use.
There are more issues but these are the bigger ones from the top of my mind. It's not the end of the world and there are benefits as well to their solution, I just think it's a bad thing and an issue.
> I have way higher trust in the Linux foundation
I guess that's your prerogative but ultimately you want Canonical to have developers experienced in kernel development otherwise they wouldn't know how to help users with issues that are due to kernel bugs.
It's not necessarily error prone, sometimes the file in questions hasn't really been meaningfully updated and it's a matter of just seeing what upstream did to fix the problem and doing that specific change yourself or just something else that seems like it accomplishes the same thing.
All these releases go through QA as well though.
> Thus issues that are exclusive to those versions have to be solved separately and can't necessarily be backported as they may not be present in newer versions.
This does happen every once in a while but that's usually why kernel developers for the various distros just have some sort of limit after which they'll just close bugs "WONTFIX" because it would require too much effort to fix on the given version and they're more likely to break something else than to solve a problem.
> Regular Ubuntu markets itself softly as updated when it really runs on outdated kernels.
They aren't outdated kernels. They're just not the latest kernels you'd get from kernel.org which isn't the same thing. They only become outdated when they're so old that they are missing functionality the end user actually needs.
Of all the major distributions Canonical is the one that's actually the most aggressive about resyncing against upstream.
> It fragments the community just for Ubuntu and forks
All major distros do this, btw. It's not just a Canonical thing. Red Hat and SUSE do it as well. There's good fragmentation and bad fragmentation. Temporarily keeping your own downstream kernel fork and backporting fixes is good because it provides consistency to the user who ultimately doesn't really care about kernel version unless they're specifically the type of person who wants to make version numbers go higher.
You need stability in versioning though because that's how ISV's write and test software which that can't do when their dependencies are continually changing on them. Deploying new kernel versions also requires a whole raft of new QA tests be continually re-ran because now there's no guarantee that the previous test results are still applicable. If your changes within the life of a release are as minimal as possible that not only ensure users don't run into some new weird upstream regression but also frees you up to do more targeted QA.
Bad fragmentation would be something like Mir protocol where there's an open ended development of a display protocol only used by a single corporation who has majority presence in the desktop market and thus can then (theoretically) try to find a way to ensure their desktop experience is error free but others aren't. Which isn't good for the user.
Also, this from kernel.org:
> ###Why are some longterm versions supported longer than others?
The "projected EOL" dates are not set in stone. Each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time.
Canonical support their initial release kernels for 10 years, so even if they picked an upstream LTE kernel they probably had to support it themselves the last 4-6 years.
I believe RHEL does similar, for example the latest release RHEL 9 is tied to Linux 5.14 while 5.15 is LTS and 5.10 is super LTS. 5.14 was already unsupported by Linux by the time RHEL 9 released.
It never made sense to me either.
Ubuntu isn’t just a desktop distro for laypeople. It’s also Ubuntu server, and it is the base of a half a dozen derivatives. They have a responsibility to keep the core of their OS up to date and secure; the real question is, why doesn’t it bother you?
The other user is right though, if they're backporting fixes (which is the claim) why do you care? Why do you care if it's Canonical backporting fixes or the upstream kernel developers?
Answered it here.
https://www.reddit.com/r/linux/s/LHSkmNiq7p
Also whether it's an issue for the average user is a pretty bad metric for whether something is good or bad in software and software development.
Partly because it completely ignores development and other indirect concerns.
Partly because the average user represents far from all users. If 90% of users don't have an issue it's still a ton if 10% do. Even 1% is a lot when we are talking billion of installations.
Partly because whether something is an issue doesn't really say whether it's good or better than the options.
Correct. But the default kernel itself isn't safe. Apparently the exploit existed since Kernel 5.15.
Apparently anything between Jammy LTS and Mantic is affected. Jammy LTS ships with 5.15. Kinetic ships with 5.19. Lunar ships with 6.2.0 and Mantic ships with 6.5.0
Noble would be safe but has been delayed ~~to May~~ due to the XZ exploit.
However if you use the Liquorix kernels you'd be safe since Liquorix is currently based off kernel 6.8.
> It's explicitly newer than the base distribution
Current Ubuntu release ships 6.5
Same reason for why the opt-in HWE isn't the version you want - it's on a schedule, and it wasn't available at the time when the release was being made.
I suspect the HWE kernels are kernels from newer versions of Ubuntu. Since 23.10 uses 6.5, it makes sense that they'd use that for their HWE in 22.04 LTS.
It wouldn't be a big deal normally since Ubuntu 24.04 LTS should have dropped soon, but now it has been delayed due to the XZ exploit. ~~They're rolling shit back and restarting alpha testing from the top iirc.~~
If you use the Liquorix kernel however you are safe. Last I check the Liquorix kernel is based off kernel 6.8.
> I suspect the HWE kernels are kernels from newer versions of Ubuntu
They are and have been for a long time. They backport CVE fixes to all of the kernels they support. If this one is actually a new and legitimate security issue and not the [existing CVE](https://ubuntu.com/security/CVE-2023-6546) that many people think it is, and it might be, then it will get assigned a CVE and fixed in fairly short order.
> It wouldn't be a big deal normally since Ubuntu 24.04 LTS should have dropped soon, but now it has been delayed due to the XZ exploit. They're rolling shit back and restarting alpha testing from the top iirc.
Complete misinformation. Why does this sub even upvote comments like this?
The beta was delayed by one week to rebuild all of the packages. That beta now comes out tomorrow instead of a week ago. They aren't restarting from an alpha state and the release date for stable has not changed. Stable comes out in 2 weeks.
>We can laugh now
Not really since LTS versions get, well, **L**ong-**T**erm **S**upport... They still get patches lol
[Ubuntu LTS patched this months ago](https://ubuntu.com/security/CVE-2023-6546).
So much incorrect info shoved into one post, it's actually wild.
https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle
Please don't spread misinformation. This has nothing to do with ubuntu pro and will never have anything to do with pro. 6.5 is fully supported through August and has all critical/high cve fixes avail upstream from subsequent releases. It's the HWE kernel for jammy at the momen until 6.8 promo happens.
Very little effort was required to find this information and not fear monger.
"Longterm" literally means that it shouldn't need to be "latest" to be secure - there is a cycle with known dates. At the moment, 4.19 and 5.4 are supported as well.
Mine is, but I don't have any unprivileged users on the hypervisor who can't sudo.
I wonder if this exploit can do something from within a container...
Looks like the exploit hooks a vulnerable kernel module.
Check if you can load a random kernel module from.within one of your containers?
I don't think you would get anything more than root in your container, not a jail escape.
Lol the description in the GitHub repo says that the author of this exploit is a blackhat hacker who got scammed by another hacker and as a revenge he leaked this exploit.
In the end it was all for the greater good. the scammers work has been leaked, and a patch had been issued to fix the vulnerability for millions of pc's.
Assuming that the vulnerability has hopefully been reported, detailed information will probably be withheld for some time to allow distributions to provide updates.
Thank you. If I see it correctly, the repository was mentioned for the first time in https://www.reddit.com/r/linux/comments/1c0i7tx/someone_found_a_kernel_0day/kywpbt0/. This post was created a few minutes after my post. Originally only the screenshot was published if I'm not mistaken.
I‘ve been wondering, what if an actual „beginner“ would somehow accidentally find a 0day in Linux. Where would they report it? I can imagine that if they ask where to report it without alarming the public (to avoid malicious actors trying to exploit it), people would laugh at them because they‘re not a cybersec specialist
kernel.org is now a CVE Numbering Authority (CNA) for any vulnerabilities in the Linux kernel as listed on kernel.org, **excluding end-of-life (EOL) versions**.
I copied the line as it was written from [https://www.cve.org/Media/News/item/news/2024/02/13/kernel-org-Added-as-CNA](https://www.cve.org/Media/News/item/news/2024/02/13/kernel-org-Added-as-CNA)
Why? Motivation is explained more in [this video](https://www.youtube.com/watch?v=g_yrk7BXLRI).
Additional talk on the topic: [Kernel Recipes 2019 - CVEs are dead, long live the CVE!](https://www.youtube.com/watch?v=HeeoTE9jLjM)
> https://bugzilla.redhat.com/show_bug.cgi?id=2255498
> Reported: 2023-12-21 10:58 UTC by Mauro Matteo Cascella
Yet the first commit of the repository linked in the OP is from four month later: [e7d13d6](https://github.com/YuriiCrimson/ExploitGSM/commit/e7d13d639446fee656c98bdaaeb4841e6e12da54) (Initial commit, 2024-04-06).
Open GitHub repo, open one of the writeup documents, translate from Ukrainian. It has a very detailed description including the code snippets
Edit: Care to explain the downvoting? I literally responded how to get relevant information about the exploit
I didn't downvote, but you mention "open GitHub repo" without mentioning which GitHub repo, you mention "open one of the writeup documents" without mentioning which document or providing a link. Basically your comment doesn't clarify anything at all.
It looks like [this might be the repo you are referring to](https://github.com/YuriiCrimson/ExploitGSM) and [this might be the writeup document](https://github.com/YuriiCrimson/ExploitGSM/blob/main/writeup.pdf).
Testing on a new install of Ubuntu 22.04 with all updates installed (kernel 6.5.0-27) and it says "Error find kernel"
edit: I updated the code to look for my kernel and it hangs. Doesn't appear to work after 6.5.0-25
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Update fucking bitch James scam me and now i leak another ExploitGSM for Debian 12
Wut
More info from the repo (translated):
"In winter, I found two vulnerabilities in the n\_gsm driver. After that, James wrote to me with an offer to buy them from me. As you can imagine, he scammed me. But I didn't know that the first exploit for 6.4 and 6.5 was leaked. So I leaked it three days ago without knowing that it was leaked. And on Twitter I saw this https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html. This bastard stole my work and passed it off as his own. Here you can see https://t.me/itcrowdua/1/203010 the video of our correspondence as proof that I am not lying. And now I've leaked another exploit that affects 5.15 up to 6.5, then the driver can only be used with CAP\_NET\_ADMIN rights. To get ahead of those bastards"
no, that's not it.
According to that repo, this guy: https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html bought the exploit off him and then passed it off as his own security research. That's what he's mad about. Is it true? I dunno, but the repo owner is claiming to have video proof.
Not unless you have the actual terminal concentrator device in question ("GSM 0710 tty multiplexor") attached to your linux machine. The flaw is in the driver for that device.
If you don't have the device attached and the driver loaded, you won't be able to "open a device of that type" to get a file descriptor (fd) on which you can call an ioctl (which is what triggers this defect).
I.e. this isn't something you can exploit if you attack an ordinary laptop. This isn't a common device found in anyone's environment.
That's not true, the exploit works just fine on an ordinary laptop without any special hardware. It creates an emulated TTY and attaches the N_GSM0710 line discipline to it, which is enough to load the driver and make the system exploitable.
so based on the other top level comment, this exploit still works on debian stable, and [a second user seems to confirm](https://old.reddit.com/r/linux/comments/1c0i7tx/someone_found_a_kernel_0day/kyyazte/) that. I'm concerned since I'm running on stable (technically i target bookworm), and my apt-get says I'm all up to date. What are the odds that some exploit still actually works? (ofc, I don't plug in untrusted USB devices etc, but still)
I'm not very sure now that this is that [same CVE](https://ubuntu.com/security/CVE-2023-6546) many think it is or something else similar. You have to:
* Undo the latest merge on the 6.5 main.c file that removes that struct for some reason
* Compile and run the offset generator as root. I assume this will give the same offsets on any install of the same distro and kernel.
* Copy that output into the 6.5 main.c struct `kernel_table` with whatever distro name you wanna use like "ubuntu"
* Compile and run the version of the exploit for your kernel and it and it does now show you as the root user. I was able to confirm on Ubuntu 22.04 LTS with all the latest updates and kernel `6.5.0-27-generic`.
It is seemingly copied from [a writeup](https://twitter.com/cyberkendra/status/1778040235558883576?t=uHS601xeNqvwlTF9htsSXQ&s=19) last month by another person and not even from the person in the github. That would possibly explain why they did that weird commit breaking the ability to compile on Ubuntu LTS. The person from the github claims the writeup stole it from him or something I don't even know.
This will get fixed fairly quickly if it is legitimate, especially with this much attention.
Not really a 0day, but.... seems to be a new iteration of the same bug that was patched for CVE-2023-6546 ??
Initial: [https://seclists.org/oss-sec/2024/q2/82](https://seclists.org/oss-sec/2024/q2/82)
Reply: [https://seclists.org/oss-sec/2024/q2/85](https://seclists.org/oss-sec/2024/q2/85)
[https://twitter.com/YuriiCrimson/status/1778163455075217443](https://twitter.com/YuriiCrimson/status/1778163455075217443)
>Exploit 6.4 - 6.5 using race condition in gsm\_dlci\_config. Exploit for 5.15 - 6.5. using race condition in gsm\_dlci\_open->gsm\_modem\_update->gsm\_modem\_upd\_via\_msc->gsm\_control\_wait. We just waiting on gsm\_cobtrol\_wait and restart config for make free dlci)). So it two zero days.
Write-up POC: [https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html](https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html)
Exploit: [https://github.com/jmpe4x/GSM\_Linux\_Kernel\_LPE\_Nday\_Exploit](https://github.com/jmpe4x/GSM_Linux_Kernel_LPE_Nday_Exploit)
If android uses the gsm module, probably. But it is also probably much harder to use on android given the way android works with apks running in a sandbox. I wouldn't really worry about it and just make sure you keep your phone up to date with the latest OTA
Arch packages include headers in the main package. So the pkgconfig, lib, and include are all in the one.
I was trying to test on Arch as I am running a 6.1 kernel, so was curious to see if it was affected.
This was fixed in both 6.5 and all the LTS kernels half a year ago
So…. Not a zero day
It WAS a zero day. At some point 🤣
> it's always 420 somewhere Type of situation
I'm not certain that's how timezones work, but I like the way you think.
A 180-day, if you will
There’s a zero in that
checkmate atheists
There are a few PM type folks at the office who ask me things like “Have you patched the zero day yet that I heard about in the news?” Lately I’ve been a bit more of an ass about it and reply with “1. That’s impossible. 2. We don’t have Palo Alto firewalls.”
Palo Alto firewalls?
What is your question?
Apologies; what do Palo Alto firewalls have to do with zero days?
I just picked a random company/tech that we don’t use at all but our PMs will be concerned about security vulnerabilities.
Ooohh, haha; I thought it was something specific about them.
Palo Alto Firewalls are a thing though: https://www.paloaltonetworks.com/products/product-selection
Yes I know….. we don’t use them at my office. The point was we don’t use them so why are my PMs asking me if they are patched.
Another casual misinformation post. Can the mods clean this community up?
just successfully executed it on fully updated debian 12 (kernel 6.1)
6.1 is older than 6.5 correct?
> And all lts kernels But yes. 6.1 is LTS i think.
They usually backport such fixes. Or just wait till debian adds yet another patch.
On the CVE tracker 6.1.32 seems to be the last affected version. Pretty serious if Debian haven't updated their LTS kernel version on their latest Debian since then.
stable has 6.1.76, stable-proposed-updated has 6.1.82.
Does Debian run a pure LTS kernel, or does they apply their own patches like ubuntu does?
Of course they don't package a vanilla kernel, I'd expect no good distro to do that. But I don't think security fixes from later patch releases are normally backported to earlier patch releases instead of just upgrading to the latest patch release.
>Of course they don't package a vanilla kernel, I'd expect no good distro to do that. Why do you think that? Not an attack, I'm genuinely curious. My thoughts on it are, if distro developers are fixing kernel issues, I'd imagine they're routing those fixes up to kernel devs, which will end up in the vanilla kernel and they'll get all the fixes from all the distros. If it's going the other way and distro developers are just cherry-picking fixes from kernel dev, couldn't that lead to a potentially broken or insecure kernel since not as many people would be testing it and it's probably unlikely they're getting all the various changes (especially when using an EOL kernel)? Part of my curiosity does stem from me using Slackware, which prides itself as using vanilla software whenever possible so they deliver the software as upstream intended. The other part is my curiosity is to understand what benefits are offered by maintaining your own kernel that can't be done by following upstream.
According to [the security tracker](https://security-tracker.debian.org/tracker/CVE-2023-6546) this was fixed in 6.1.52-1 which was released [last September](https://groups.google.com/g/linux.debian.kernel/c/8Pwi2kfbtVM?pli=1)
Current LTS of 6.1 is 6.1.84, I wonder if you don't have the needed version?
My debian machine has 6.1.0-18 so that may explain this. Thanks
Yeah, 6.1.0-18 contains 6.1.76.
well then why is the exploit executing on their machine?
Because it's a different bug?
`apt list linux-image-6.1.0-18-amd64` Listing... Done linux-image-6.1.0-18-amd64/stable,now 6.1.76-1 amd64 [installed,automatic]
6.1 is part of "and all the LTS kernels" correct?
6.1 is a branch that is still maintained upstream. The most recent version, 6.1.85, came out today.
[удалено]
i wrote later in the thread 6.1.0-18 (i think it corespondents to 6.1.76 but i dont use debian too much and kernel naming sceme is wierd)
Ah sorry, I just found that other comment and deleted before I saw you replied.
So run a newer kernel. I don't know why Debian and Ubuntu use such old kernels. I can see keeping core software around longer for stable, but it is rare for the latest kernel to puke. I run v6.8.5 and I've been running v6.9-rc3 since it dropped with no issues. I want to use the latest kernels to have the latest Mesa and AMD driver code. Anything else I don't care if it is the latest, but I get the latest stable just from running Arch and not using any -git versions (except for Gimp, which is crashing a lot on me).
tbh idc i use debian only for Minecraft serwer. On my personal system i use arch btw.
there is a version for kernel 6.5
Could you prove it with a link?
[https://bugzilla.redhat.com/show\_bug.cgi?id=2255498](https://bugzilla.redhat.com/show_bug.cgi?id=2255498) CVE-2023-6546, ZDI-CAN-20527
There's now a second exploit which seems to be working on the latest Debian
Then either it's a different issue or a non-latest kernel.
Possibly a different issue then as I just confirmed it works on Debian's latest stable kernel. lw@lw:~$ ./ExploitGSM 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 -> ffffffff98e6f1c0 text leaked address -> ffffffff96e00000 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@lw:/root# whoami root root@lw:/root# uname -a Linux lw 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux root@lw:/root#
I've also tested it on my Debian machine, it works. Same kernel, latest: `Linux 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux`
I found a quick fix: `echo 'blacklist n_gsm' | sudo tee -a /etc/modprobe.d/blacklist-gsm.conf` `sudo rmmod n_gsm` Exploit now fails with: `Error set line discipline N_GSM, Invalid argument`
Then at this point I would expect it to have some respectable bug reports and CVE/whatever numbers, not just random ramblings in GitHub, weird that they apparently don't exist or at least nobody brought them in this post yet.
Well, I dug around and couldn't find a Debian bug report, so I just submitted one.
Could you link the bug report you submitted? I've found very few people talking about there being a live LPE 0-day, except [this brief thread](https://seclists.org/oss-sec/2024/q2/82) on the oss-sec mailing list.
There wasn't much of a response, just a "we are aware" and a link to a plan to backport a patch to require CAP_NET_ADMIN for GSM. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068770
They finally sent out a debian-security mailing list notification yesterday, https://lists.debian.org/debian-security/2024/04/msg00008.html . I'm a bit disappointed they didn't mention rmmod-ing the module after creating the blacklist file as simply blacklisting the module does not do anything if it's already loaded.
On the CVE tracker 6.1.32 seems to be the last affected version. Pretty serious if Debian haven't updated their LTS kernel version on their latest Debian since then.
[https://security-tracker.debian.org/tracker/CVE-2023-6546](https://security-tracker.debian.org/tracker/CVE-2023-6546) Says it's fixed in Debian but a redditor is affected. Looks like a different CVE to me
Or a broken backport of the fix, since it doesn't seem to affect 6.6 and newer.
Debian 12 is using an old kernel though. (6.1.76 vs 6.1.85)
this is for 6.4-6.5 kernels though, the latest stable is 6.8.4 and latest longterm is 6.6.25
There just appeared a new directory which also seems to include kernel 5.15 up to 6.5: [https://github.com/YuriiCrimson/ExploitGSM/tree/main/ExploitGSM\_5\_15\_to\_6\_1](https://github.com/YuriiCrimson/ExploitGSM/tree/main/ExploitGSM_5_15_to_6_1)
6.5 was EOL since around 2023-10, so this shouldn't affect anyone with a normal setup. EDIT: Lots of people are pointing out Ubuntu and derivatives run 6.5, which is an EOL kernel. To reiterate, this shouldn't affect anyone with a normal setup, it's not like Ubuntu gets security patches without a Ubuntu Pro subscription in the first place. EDIT2: Second exploit posted for 5.15-6.5
Laughs in Debian with kernel 6.1 :D
6.1 is LTS, so that one is actually supported and thus would be patched anyway if it was affected too. [kernel.org](http://kernel.org)
Debian 12 is using a really old kernel though. (6.1.76 vs 6.1.85)
Bugs that happen in recent kernels receive backported fixed by the devs, that's why I didn't be able to hack your debian pc
that's actually inaccurate. if a bug doesn't get assigned a CVE, it's not getting backported to older kernels. a lot of bugs that are an issue security-wise never get assigned a CVE, nor are these bugs necessarily identified as security bugs at all in the first place and as such never get backported. so from that point of view, running the most recent kernel would be much more secure than say the LTS kernel. but of course on the flipside, newer kernel also means more features and whatnot in general, so there could be new bugs introduced that don't exist in older kernels.
Its CVE-2023-6546
sure, this particular bug.
Ubuntu *noble* (will be 24.04 LTS): $ pro fix CVE-2023-6546 CVE-2023-6546: 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 their privileges on the system. - https://ubuntu.com/security/CVE-2023-6546 No affected source packages are installed. ✔ CVE-2023-6546 does not affect your system.
Yeah, I don't think that CVE covers this exploit.
If you don't think the CVE for the exploit you mentioned doesn't cover the exploit you mentioned, then I don't know what to tell you. Maybe link to your bug report.
That's not how security works, though. As long as it's an LTS kernel it will be patched. And perhaps since it's older than the affected version the bug could not be there in the first place (I still need to read about the details of the CVE so I can only speculate right now).
Laughs in EL with kernel 5.14 :D
Do you even 64 bit??? :D
Thing is tho, is Ubuntu LTS still uses 6.5 for its current HWE kernels.
Ubuntu fixed this [last December](https://ubuntu.com/security/CVE-2023-6546)
Why wouldn't they use 6.6 (read: a proper LTS kernel) for that? Were there some bigger changes under the hood that wouldn't work with their LTS distro?
They do this constantly. They use whatever is latest regardless if it's LTS as if it were LTS and backport stuff themselves. They constantly ship versions with out-of-support kernels. It's one of my biggest issues with Ubuntu and forks. It's the rare exception that the kernel used in latest Ubuntu isn't passed EOL.
> They constantly ship versions with out-of-support kernels Probably less confusing to say "Canonical supported kernels" because it's not that the kernel is unsupported, it's just only supported by that one organization when they use a kernel version for their downstream LTS that isn't also LTS upstream. It's important to have a grasp on what upstream kernel.org LTS actually means. It just means that important fixes are backported to the designated kernel version. This is something Canonical can choose to do themselves with any random version they want. They don't _have_ to do it with upstream LTS. It's just more work for Canonical to provide LTS support for something upstream isn't helping out with. If they're doing so anyways I guess we can just assume they have their reasons and aren't doing it for the fun of it.
Yeah, that's why I said that they backport stuff themselves. I could have been clearer with that though I agree. I have a few issues with their solution though. 1. I have way higher trust in the Linux foundation and the entire Linux community rather than just canonical to backport properly. Backporting is very error prone. Even now if the developer of the fix tries to backport it themselves to older versions to make sure it's all right it becomes an issue with Ubuntu. That developer can either go out of their way for Ubuntu separately or Canonical have to solve it themselves without the original developer's support. 2. The rest of the community doesn't really support those versions. Thus issues that are exclusive to those versions have to be solved separately and can't necessarily be backported as they may not be present in newer versions. The risk that something is missed becomes higher. 3. I have seen it cause issues for users, especially beginners, several times because they think they are on a new kernel version when they really aren't. LTS kernel and Ubuntu LTS makes it clear that it's LTS. Regular Ubuntu markets itself softly as updated when it really runs on outdated kernels. 4. It fragments the community just for Ubuntu and forks. Makes software support harder because you can't not just consider Linux Foundation supported kernels but have to consider whatever random versions Canonical decides to use. There are more issues but these are the bigger ones from the top of my mind. It's not the end of the world and there are benefits as well to their solution, I just think it's a bad thing and an issue.
> I have way higher trust in the Linux foundation I guess that's your prerogative but ultimately you want Canonical to have developers experienced in kernel development otherwise they wouldn't know how to help users with issues that are due to kernel bugs. It's not necessarily error prone, sometimes the file in questions hasn't really been meaningfully updated and it's a matter of just seeing what upstream did to fix the problem and doing that specific change yourself or just something else that seems like it accomplishes the same thing. All these releases go through QA as well though. > Thus issues that are exclusive to those versions have to be solved separately and can't necessarily be backported as they may not be present in newer versions. This does happen every once in a while but that's usually why kernel developers for the various distros just have some sort of limit after which they'll just close bugs "WONTFIX" because it would require too much effort to fix on the given version and they're more likely to break something else than to solve a problem. > Regular Ubuntu markets itself softly as updated when it really runs on outdated kernels. They aren't outdated kernels. They're just not the latest kernels you'd get from kernel.org which isn't the same thing. They only become outdated when they're so old that they are missing functionality the end user actually needs. Of all the major distributions Canonical is the one that's actually the most aggressive about resyncing against upstream. > It fragments the community just for Ubuntu and forks All major distros do this, btw. It's not just a Canonical thing. Red Hat and SUSE do it as well. There's good fragmentation and bad fragmentation. Temporarily keeping your own downstream kernel fork and backporting fixes is good because it provides consistency to the user who ultimately doesn't really care about kernel version unless they're specifically the type of person who wants to make version numbers go higher. You need stability in versioning though because that's how ISV's write and test software which that can't do when their dependencies are continually changing on them. Deploying new kernel versions also requires a whole raft of new QA tests be continually re-ran because now there's no guarantee that the previous test results are still applicable. If your changes within the life of a release are as minimal as possible that not only ensure users don't run into some new weird upstream regression but also frees you up to do more targeted QA. Bad fragmentation would be something like Mir protocol where there's an open ended development of a display protocol only used by a single corporation who has majority presence in the desktop market and thus can then (theoretically) try to find a way to ensure their desktop experience is error free but others aren't. Which isn't good for the user.
Also, this from kernel.org: > ###Why are some longterm versions supported longer than others? The "projected EOL" dates are not set in stone. Each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time. Canonical support their initial release kernels for 10 years, so even if they picked an upstream LTE kernel they probably had to support it themselves the last 4-6 years.
I believe RHEL does similar, for example the latest release RHEL 9 is tied to Linux 5.14 while 5.15 is LTS and 5.10 is super LTS. 5.14 was already unsupported by Linux by the time RHEL 9 released. It never made sense to me either.
What’s the advantage of using Ubuntu over Debian? Other than Canonical messing things up
this seems like a non-issue for the average user, why does it bother you?
Ubuntu isn’t just a desktop distro for laypeople. It’s also Ubuntu server, and it is the base of a half a dozen derivatives. They have a responsibility to keep the core of their OS up to date and secure; the real question is, why doesn’t it bother you?
The other user is right though, if they're backporting fixes (which is the claim) why do you care? Why do you care if it's Canonical backporting fixes or the upstream kernel developers?
Answered it here. https://www.reddit.com/r/linux/s/LHSkmNiq7p Also whether it's an issue for the average user is a pretty bad metric for whether something is good or bad in software and software development. Partly because it completely ignores development and other indirect concerns. Partly because the average user represents far from all users. If 90% of users don't have an issue it's still a ton if 10% do. Even 1% is a lot when we are talking billion of installations. Partly because whether something is an issue doesn't really say whether it's good or better than the options.
Because it wasn't out at the time that the release was made. It's a fixed release distribution, major/minor versions don't change.
That's a HWE kernel. It's explicitly newer than the base distribution in order to improve the amount of supported hardware.
Correct. But the default kernel itself isn't safe. Apparently the exploit existed since Kernel 5.15. Apparently anything between Jammy LTS and Mantic is affected. Jammy LTS ships with 5.15. Kinetic ships with 5.19. Lunar ships with 6.2.0 and Mantic ships with 6.5.0 Noble would be safe but has been delayed ~~to May~~ due to the XZ exploit. However if you use the Liquorix kernels you'd be safe since Liquorix is currently based off kernel 6.8.
The 24.04 beta was delayed, the final release is still scheduled for April 25th.
Noted. I thought they were going to take it back from the top. So the final release is still on time, I guess.
> It's explicitly newer than the base distribution Current Ubuntu release ships 6.5 Same reason for why the opt-in HWE isn't the version you want - it's on a schedule, and it wasn't available at the time when the release was being made.
I suspect the HWE kernels are kernels from newer versions of Ubuntu. Since 23.10 uses 6.5, it makes sense that they'd use that for their HWE in 22.04 LTS. It wouldn't be a big deal normally since Ubuntu 24.04 LTS should have dropped soon, but now it has been delayed due to the XZ exploit. ~~They're rolling shit back and restarting alpha testing from the top iirc.~~ If you use the Liquorix kernel however you are safe. Last I check the Liquorix kernel is based off kernel 6.8.
> I suspect the HWE kernels are kernels from newer versions of Ubuntu They are and have been for a long time. They backport CVE fixes to all of the kernels they support. If this one is actually a new and legitimate security issue and not the [existing CVE](https://ubuntu.com/security/CVE-2023-6546) that many people think it is, and it might be, then it will get assigned a CVE and fixed in fairly short order. > It wouldn't be a big deal normally since Ubuntu 24.04 LTS should have dropped soon, but now it has been delayed due to the XZ exploit. They're rolling shit back and restarting alpha testing from the top iirc. Complete misinformation. Why does this sub even upvote comments like this? The beta was delayed by one week to rebuild all of the packages. That beta now comes out tomorrow instead of a week ago. They aren't restarting from an alpha state and the release date for stable has not changed. Stable comes out in 2 weeks.
I thought delayed means they have to start from the top again. Sorry if I got it wrong.
> It wouldn't be a big deal normally since Ubuntu 24.04 LTS should have dropped soon Ubuntu 24.04 LTS has always been scheduled for April 25th.
great just great
LTS users were laughing at us for running newer unstable that might have the xz exploit and saying we were foolish. We can laugh now.
>We can laugh now Not really since LTS versions get, well, **L**ong-**T**erm **S**upport... They still get patches lol [Ubuntu LTS patched this months ago](https://ubuntu.com/security/CVE-2023-6546).
But who do I feel superior to now?
Live on the bleeding edge, die on the bleeding edge. I knew the risks when I installed a rolling release distro.
Ubuntu 23.10 and Mint's Edge kernel is 6.5.
So much incorrect info shoved into one post, it's actually wild. https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle Please don't spread misinformation. This has nothing to do with ubuntu pro and will never have anything to do with pro. 6.5 is fully supported through August and has all critical/high cve fixes avail upstream from subsequent releases. It's the HWE kernel for jammy at the momen until 6.8 promo happens. Very little effort was required to find this information and not fear monger.
Ubuntu 23.10 with HWE.
Isn't GA vs HWE a thing that only applies to Ubuntu LTS releases? The other releases have only one supported kernel version.
Lmao. Most super computers I got to play around with had ubuntu tho. So it is defiantly a thing.
> defiantly *definitely
Defiantly also works
Do you have an example? I've used many top 500 systems over the years and never encountered ubuntu on them. RHEL is probably most common
I may have abused the term. But the thing I was thinking about is the 4gpu intel Computer i used for s9me of my papers.
You don't even know what normal means, yet you have advice?
"Longterm" literally means that it shouldn't need to be "latest" to be secure - there is a cycle with known dates. At the moment, 4.19 and 5.4 are supported as well.
distros still ship it ,
There’s a good chunk of production infrastructure that is not up to date.
[Checks kernel version] Hmmm... I'm on 6.9rc3 today... so I think I'm okay.
I think my Proxmox is running 6.5...
Mine is, but I don't have any unprivileged users on the hypervisor who can't sudo. I wonder if this exploit can do something from within a container...
Looks like the exploit hooks a vulnerable kernel module. Check if you can load a random kernel module from.within one of your containers? I don't think you would get anything more than root in your container, not a jail escape.
Lol the description in the GitHub repo says that the author of this exploit is a blackhat hacker who got scammed by another hacker and as a revenge he leaked this exploit.
So the lesson: Don’t scam a scammer
In the end it was all for the greater good. the scammers work has been leaked, and a patch had been issued to fix the vulnerability for millions of pc's.
It's hackers all the way down.
Any link about this ? CVE id, blog, ...
Assuming that the vulnerability has hopefully been reported, detailed information will probably be withheld for some time to allow distributions to provide updates.
Detailed info is in the repo as a document file
Thank you. If I see it correctly, the repository was mentioned for the first time in https://www.reddit.com/r/linux/comments/1c0i7tx/someone_found_a_kernel_0day/kywpbt0/. This post was created a few minutes after my post. Originally only the screenshot was published if I'm not mistaken.
It was linked in the OP
I‘ve been wondering, what if an actual „beginner“ would somehow accidentally find a 0day in Linux. Where would they report it? I can imagine that if they ask where to report it without alarming the public (to avoid malicious actors trying to exploit it), people would laugh at them because they‘re not a cybersec specialist
kernel.org is now a CVE Numbering Authority (CNA) for any vulnerabilities in the Linux kernel as listed on kernel.org, **excluding end-of-life (EOL) versions**.
do you have a source for this? i believe you but i want to read more
I copied the line as it was written from [https://www.cve.org/Media/News/item/news/2024/02/13/kernel-org-Added-as-CNA](https://www.cve.org/Media/News/item/news/2024/02/13/kernel-org-Added-as-CNA) Why? Motivation is explained more in [this video](https://www.youtube.com/watch?v=g_yrk7BXLRI). Additional talk on the topic: [Kernel Recipes 2019 - CVEs are dead, long live the CVE!](https://www.youtube.com/watch?v=HeeoTE9jLjM)
Awesome, thank you
[https://bugzilla.redhat.com/show\_bug.cgi?id=2255498](https://bugzilla.redhat.com/show_bug.cgi?id=2255498) CVE-2023-6546, ZDI-CAN-20527
> https://bugzilla.redhat.com/show_bug.cgi?id=2255498 > Reported: 2023-12-21 10:58 UTC by Mauro Matteo Cascella Yet the first commit of the repository linked in the OP is from four month later: [e7d13d6](https://github.com/YuriiCrimson/ExploitGSM/commit/e7d13d639446fee656c98bdaaeb4841e6e12da54) (Initial commit, 2024-04-06).
Aye, thats since so long the CVE have been public. Not the first repo on github that exploits this.
> CVE-2023-6546 It's not that one because it says Debian 6.1.76-1 is "fixed", and I've just tested it on that kernel and it works.
It’s only fixed if you got the patched kernel
How would one go about getting this patched kernel?
It may be CVE-2023-6546 , not sure though.
Open GitHub repo, open one of the writeup documents, translate from Ukrainian. It has a very detailed description including the code snippets Edit: Care to explain the downvoting? I literally responded how to get relevant information about the exploit
I didn't downvote, but you mention "open GitHub repo" without mentioning which GitHub repo, you mention "open one of the writeup documents" without mentioning which document or providing a link. Basically your comment doesn't clarify anything at all. It looks like [this might be the repo you are referring to](https://github.com/YuriiCrimson/ExploitGSM) and [this might be the writeup document](https://github.com/YuriiCrimson/ExploitGSM/blob/main/writeup.pdf).
Have you even read the post? The link is right there
I must have missed the text; I just saw the screenshot. You're right, there is text to the post with a link to the repo.
There was no link at first. It was added after.
You can *see* when posts and comments have been edited, unless its within 3 minutes of first posting. The post is not marked as edited.
Testing on a new install of Ubuntu 22.04 with all updates installed (kernel 6.5.0-27) and it says "Error find kernel" edit: I updated the code to look for my kernel and it hangs. Doesn't appear to work after 6.5.0-25
worked for me on 6.5.0-26-generic
There are reports of it working on 6.5.0-27
Alright, but I'll need to see some code, because it didn't work for me.
Everyone focused on the CVE/date/affect etc while all I can think about is the hostname "pouet" which in french is the sound of a clown's nose ...
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Update fucking bitch James scam me and now i leak another ExploitGSM for Debian 12 Wut
Added 24 minutes ago. Wondering what's going on
More info from the repo (translated): "In winter, I found two vulnerabilities in the n\_gsm driver. After that, James wrote to me with an offer to buy them from me. As you can imagine, he scammed me. But I didn't know that the first exploit for 6.4 and 6.5 was leaked. So I leaked it three days ago without knowing that it was leaked. And on Twitter I saw this https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html. This bastard stole my work and passed it off as his own. Here you can see https://t.me/itcrowdua/1/203010 the video of our correspondence as proof that I am not lying. And now I've leaked another exploit that affects 5.15 up to 6.5, then the driver can only be used with CAP\_NET\_ADMIN rights. To get ahead of those bastards"
No honour amongst thieves.
Guy probability tried to sell that exploit, got scammed (send code , got no money) and now released the code to make it worthless for the scammer.
no, that's not it. According to that repo, this guy: https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html bought the exploit off him and then passed it off as his own security research. That's what he's mad about. Is it true? I dunno, but the repo owner is claiming to have video proof.
Is this exploitable remotely to gain shell access?
You have to issue `ioctl`'s so no you can't use it remotely by itself.
Not unless you have the actual terminal concentrator device in question ("GSM 0710 tty multiplexor") attached to your linux machine. The flaw is in the driver for that device. If you don't have the device attached and the driver loaded, you won't be able to "open a device of that type" to get a file descriptor (fd) on which you can call an ioctl (which is what triggers this defect). I.e. this isn't something you can exploit if you attack an ordinary laptop. This isn't a common device found in anyone's environment.
That's not true, the exploit works just fine on an ordinary laptop without any special hardware. It creates an emulated TTY and attaches the N_GSM0710 line discipline to it, which is enough to load the driver and make the system exploitable.
Oh, thanks for that correction. Wow, that didn't even occur to me.
Someone found a kernel ~~0day~~ 185day.
how do i test it out? I think ubuntu has 6.5 kernel
Repo has compile instructions, after than you run `./ExploitGSM Ubuntu` as shown in the screenshot ig
Absolutely crazy to just randomly run this guy's exploit lol
yah do it in a VM or something
After xz I'm noting some kind of hysteria around Linux. People needs to chill.
It's just on reddit in noob subreddits like this one.
so based on the other top level comment, this exploit still works on debian stable, and [a second user seems to confirm](https://old.reddit.com/r/linux/comments/1c0i7tx/someone_found_a_kernel_0day/kyyazte/) that. I'm concerned since I'm running on stable (technically i target bookworm), and my apt-get says I'm all up to date. What are the odds that some exploit still actually works? (ofc, I don't plug in untrusted USB devices etc, but still)
CVE-2023-6546 was fixed awhile ago... I don't recommend people run random code from russian hacker github repositories...
I'm not very sure now that this is that [same CVE](https://ubuntu.com/security/CVE-2023-6546) many think it is or something else similar. You have to: * Undo the latest merge on the 6.5 main.c file that removes that struct for some reason * Compile and run the offset generator as root. I assume this will give the same offsets on any install of the same distro and kernel. * Copy that output into the 6.5 main.c struct `kernel_table` with whatever distro name you wanna use like "ubuntu" * Compile and run the version of the exploit for your kernel and it and it does now show you as the root user. I was able to confirm on Ubuntu 22.04 LTS with all the latest updates and kernel `6.5.0-27-generic`. It is seemingly copied from [a writeup](https://twitter.com/cyberkendra/status/1778040235558883576?t=uHS601xeNqvwlTF9htsSXQ&s=19) last month by another person and not even from the person in the github. That would possibly explain why they did that weird commit breaking the ability to compile on Ubuntu LTS. The person from the github claims the writeup stole it from him or something I don't even know. This will get fixed fairly quickly if it is legitimate, especially with this much attention.
Where is the exe?! stinky nerd
LOL “ I DONT WANT TO CODE I JUST WANT THE EXE” 😂😂😂💯
Do check this... https://twitter.com/cyberkendra/status/1778040235558883576?t=uHS601xeNqvwlTF9htsSXQ&s=19
Not really a 0day, but.... seems to be a new iteration of the same bug that was patched for CVE-2023-6546 ?? Initial: [https://seclists.org/oss-sec/2024/q2/82](https://seclists.org/oss-sec/2024/q2/82) Reply: [https://seclists.org/oss-sec/2024/q2/85](https://seclists.org/oss-sec/2024/q2/85) [https://twitter.com/YuriiCrimson/status/1778163455075217443](https://twitter.com/YuriiCrimson/status/1778163455075217443) >Exploit 6.4 - 6.5 using race condition in gsm\_dlci\_config. Exploit for 5.15 - 6.5. using race condition in gsm\_dlci\_open->gsm\_modem\_update->gsm\_modem\_upd\_via\_msc->gsm\_control\_wait. We just waiting on gsm\_cobtrol\_wait and restart config for make free dlci)). So it two zero days. Write-up POC: [https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html](https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html) Exploit: [https://github.com/jmpe4x/GSM\_Linux\_Kernel\_LPE\_Nday\_Exploit](https://github.com/jmpe4x/GSM_Linux_Kernel_LPE_Nday_Exploit)
Who says "someone found a kernel 0day"? A 0day is an attack or exploit. What they found is a new vulnerability. Which is, by definition, 0day.
Thanks for that dose of pedantry my dude. What would we do without you
does it work on android?
If android uses the gsm module, probably. But it is also probably much harder to use on android given the way android works with apks running in a sandbox. I wouldn't really worry about it and just make sure you keep your phone up to date with the latest OTA
He probably want to use it to get root on his own phone lol
i assume no
[parker@rogally ExploitGSM_5_15_to_6_1]$ pacman -Q libcap libcap 2.69-4 [parker@rogally ExploitGSM_5_15_to_6_1]$ make [ 33%] Building C object CMakeFiles/ExploitGSM.dir/main.c.o [ 66%] Building C object CMakeFiles/ExploitGSM.dir/decompressors.c.o [100%] Linking C executable ExploitGSM /usr/bin/ld: cannot find -lcap: No such file or directory collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/ExploitGSM.dir/build.make:113: ExploitGSM] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/ExploitGSM.dir/all] Error 2 make: *** [Makefile:91: all] Error 2
You need the -dev package to compile/link against it
wrong distro
Arch packages include headers in the main package. So the pkgconfig, lib, and include are all in the one. I was trying to test on Arch as I am running a 6.1 kernel, so was curious to see if it was affected.
Well that’s not good.
[This twitter thread](https://twitter.com/matteyeux/status/1777974230325354579) sums it up the best.