Live data from Hacker News

Dirty Frag: Universal Linux LPE

openwall.com

261–270 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#261
post #143
post #53

Earlier quoted context omitted.

Are they already vulnerable to RCE as an unprivileged user? Hopefully not. An LPE only allows an attacker who can already execute code on the system to become root. So, bad, yes, but it doesn't mean you are immediately pwned.

Should I rush to Lambda or ECS and turn off all my containers sharing a host with who the hell knows?

Firecracker is extremely hardened, so I wouldn't worry about Lambda. As for ECS, getting root doesn't necessarily mean you have a container escape. I think you could escape containers with this exploit, but you would need a different payload than what's published. I could be wrong though.

I would assume AWS is pretty on the ball when it comes to handling stuff like this if they didn't have other defenses or mitigations in place already.

Re: Dirty Frag: Universal Linux LPE

#262
post #219

Earlier quoted context omitted.

Unless your Android doesn’t get any security updates anymore. https://durovscode.com/google-android-security-update-warnin...

That is a well know and entirely different issue

Is it?

The claim is Android is much more secure than other Linux, but if 40% of all Android devices don‘t get a security patch and you can’t even do it yourself I would call the more secure per se.

Hardening is one part of security, patchability another. Android lacks in the latter.

Re: Dirty Frag: Universal Linux LPE

#263
post #256
post #170

After all these years, we finally have enough eyeballs that all bugs are shallow, and it kinda sucks. How many times a week am I going to be updating my kernel from now on?

With how things are going the question should be ‘is twice a day often enough?’

At the moment it doesn't seem to be.

Within an hour of be advised of, and running the mitigation for DirtyFrag, my upstream provider has blocked all WHM/cPanel/SSH/FTP/SFTP access with a heads-up on:

CVE-2026-29201 CVE-2026-29202 CVE-2026-29203

which look like a repeat of CVE-2026-41940 a week ago.

Re: Dirty Frag: Universal Linux LPE

#264
post #153
post #13

I'm curious what broke the embargo. Did it leak or did a third party find it independently?

No embargo exists (or could possibly exist) in the first place. Linux is open source, so every patch fixing the security bug is immediately visible to everyone. There is no workaround to that by the very design how the kernel is developed. The "embargo" people talking about is the rather stupid notion that if people keep their mouth shut and not write "THIS IS A LPE" straight in the patch description, everyone can pr…

Linux does actually have a proper embargo process. But, you're correct that in this case it wouldn't usually have been followed anyway. Bugs like this are fixed multiple times a week, anyone with basic kernel knowledge can see that they are potentially LPEs.

Usually, nobody even bothers to check. LPEs like this are too common to even categorise effectively.

Re: Dirty Frag: Universal Linux LPE

#265
Looks like the esp4 and esp6 fixes have been pushed for 7.0, 6.18, 6.12 and 6.6 kernels.

https://lore.kernel.org/lkml/2026050851-iron-hurdle-6421@gre...

https://lore.kernel.org/lkml/2026050843-unplowed-spinster-cf...

https://lore.kernel.org/lkml/2026050832-remold-faceless-bed0...

https://lore.kernel.org/lkml/2026050825-heaving-spender-13a8...

Re: Dirty Frag: Universal Linux LPE

#266
post #143
post #53

Earlier quoted context omitted.

Are they already vulnerable to RCE as an unprivileged user? Hopefully not. An LPE only allows an attacker who can already execute code on the system to become root. So, bad, yes, but it doesn't mean you are immediately pwned.

Should I rush to Lambda or ECS and turn off all my containers sharing a host with who the hell knows?

AFAIK Lambda and everything else will use micro-VMs. No serious company would use a shared kernel design for workloads in different security contexts. (Personally I wouldn't even use the same hardware host, but sometimes sacrifices have to be made)

Re: Dirty Frag: Universal Linux LPE

#267

Earlier quoted context omitted.

With physical access, root access is as simple as setting init=/bin/bash in the kernel parameters from a bootloader. No need for credentials or anything.

Secure boot and disk enryption are not that unusual nowdays

Secure boot doesn't provide security, just control for device manufacturers.

Physical access always means the device is pwned. You can install a keylogger or something similar.

Re: Dirty Frag: Universal Linux LPE

#268
post #265

Looks like the esp4 and esp6 fixes have been pushed for 7.0, 6.18, 6.12 and 6.6 kernels. https://lore.kernel.org/lkml/2026050851-iron-hurdle-6421@gre... https://lore.kernel.org/lkml/2026050843-unplowed-spinster-cf... https://lore.kernel.org/lkml/2026050832-remold-faceless-bed0... https://lore.kernel.org/lkml/2026050825-heaving-spender-13a8...

And again it's band-aiding the problem. Can authencesn not be fixed or what?

Re: Dirty Frag: Universal Linux LPE

#269
post #262

Earlier quoted context omitted.

That is a well know and entirely different issue

Is it? The claim is Android is much more secure than other Linux, but if 40% of all Android devices don‘t get a security patch and you can’t even do it yourself I would call the more secure per se. Hardening is one part of security, patchability another. Android lacks in the latter.

You can take many computers from 1999 and update them to the best software available today. Most phones won't even do that for a few years. And that is security in the real sense of the word, as in "this won't just pull the rug from under me".

(Of course the problem isn't Android, it's the chipset vendors that the SW depends on. They drop support fast and never give enough info for anyone else to keep things up to date. Also Google.)

Re: Dirty Frag: Universal Linux LPE

#270
I'm not a security expert, but I'm responsible for some (relatively low-stakes) production systems.

It sounds like these two most recent exploits depend on unprivileged user namespaces, and that in fact a high percentage of LPE exploits need this feature. I use rootless containers on a couple of systems (like my dev machine server), but on most of my systems I don't, so it sounds like disabling that would be a good step to hardening my systems against future exploits.

To the security experts: are there any other straightforward configuration changes with such broad-reaching improvement in security posture? Any well-written guides on this subject, something like "top kernel modules to consider disabling if you don't need them"? I'm not talking about the obvious stuff like "disable password SSH", I'm specifically looking for steps that are statistically likely to prevent as-yet-unknown privilege escalation attacks.

Post reply on HN