Dirty Frag: Universal Linux LPE • Hacker News Board

Re: Dirty Frag: Universal Linux LPE

#131

Post by akdev1l » Thu, May 07, 2026, 10:27 PM UTC

chromacity wrote: post #123

JeremyNT wrote: post #119

Earlier quoted context omitted.

Distro maintainers blacklisting specific functionality because they believe YAGNI is a pretty big ask. They just don't know who is using what. It's always possible for users to go back and tailor their builds for the stuff they actually want. And... I remember the early days of Linux where I ran `make menuconfig` and selected exactly the functionality I wanted in my kernel. I'd... rather not end up back there. That s…

You can make precisely the same argument for network services. Who knows, maybe you need telnet and UUCP and NFS and ftpd running on your system?... why should the distro maintainer decide? Well, because you probably don't, and it's a security risk, so no need to put millions at risk for the benefit of that one person who wants to tinker with packet radio or whatever. Similarly, it would be prudent for distros to not…

The thing is that we could simply split those modules into separate packages

No reason why you couldn’t just `dnf install -y kmod-rxrpc` if for whatever reason you need that.

Re: Dirty Frag: Universal Linux LPE

#132

Post by semiquaver » Thu, May 07, 2026, 10:28 PM UTC

toast0 wrote: post #105

eqvinox wrote: post #100

Earlier quoted context omitted.

"proper read-write mode" for the input fd is reading only. The exploit is writing to the splice() input fd. Also, NB, I said permission check, not mode check. The input fd to splice can and will be open for only reading quite often. Doesn't mean the kernel can't still do a write permission check. (Except I didn't say that here. Oops. Getting confused with my posts.)

OK, I may likely have too much sleep debt to understand, but given the bug is that splice can write to the input fd, you're suggesting maybe splice should only let you use an input fd if the process has access to write to it? But splice is a more or less a generalization of sendfile, and sendfile is often used for webserving where the serving process does not have ownership of the documents it is serving. It doesn't…

Aren’t you just saying “don’t write bugs?”

Re: Dirty Frag: Universal Linux LPE

#133

Post by akerl_ » Thu, May 07, 2026, 10:28 PM UTC

chromacity wrote: post #127

akerl_ wrote: post #116

Earlier quoted context omitted.

It’s not enabled by default. It’s an optional module that is loaded on demand. The entire setup of the kernel promotes compiling in the core set of things your users will need and offering basically everything else as a module to load on demand.

This is a pedantry for the sake of it. If it's present by default and an attacker can trivially cause it to be loaded, it's the same as "on by default".

It’s radically different than on by default.

Having a service that automatically starts and listens on the network is radically different from having a module that a local administrator can load.

If you want to block module loads, you’re one sysctl flag away.

Re: Dirty Frag: Universal Linux LPE

#134

Post by dundarious » Thu, May 07, 2026, 10:29 PM UTC

john_strinlai wrote: post #71

dundarious wrote: post #65

Earlier quoted context omitted.

You can't sudo echo and redirect from the non-sudo shell like that. echo 3 | sudo tee /proc/sys/vm/drop_caches or sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' Also fixed your typo in /proc...

thanks. copy pasting from the github via my phone, and should have taken the extra few mins

No worries, overall a very useful summary comment.

Re: Dirty Frag: Universal Linux LPE

#135

Post by ActorNightly » Thu, May 07, 2026, 10:29 PM UTC

chromacity wrote: post #85

If this indeed works on all major distributions, I just continue to be amazed by how irresponsible the maintainers are. We're talking about optional kernel functionality that's presumably useful to something like This feels like the practice of Linux distros back in 1999 when they'd ship default installs with dozens of network services exposed to the internet. Except it's not 1999 anymore.

Because in order to exploit this, you have to have direct access to the computer. Either through malicious usb device, or by exploiting some supply chain or a known piece of software that will be willingly or automatically installed, and furthermore you need to be able to essentially run arbitrary terminal commands, which is a huge breach of isolation in that software.

If an attacker manages to do all that, its already bad news for you. Escalation to root with this is the least of your worries at that point.

Like someone else below posted, https://xkcd.com/1200/

People need to understand what the vulnerability actually is before freaking out about it.

Re: Dirty Frag: Universal Linux LPE

#136

Post by [deleted] » Thu, May 07, 2026, 10:31 PM UTC

[deleted]

Re: Dirty Frag: Universal Linux LPE

#137

Post by ahartmetz » Thu, May 07, 2026, 10:32 PM UTC

cluckindan wrote: post #112

angry_octet wrote: post #86

Earlier quoted context omitted.

This is really not a correct statement beyond the fact that both are a type of Unix.

Linux is not Unix: it is not derived from AT&T Unix.

Linux 2.2 or 2.4 or so (possibly only Suse Linux) even had a kernel startup message "Unix compliance testing by UNIFIX" or something, back when Unix was considered more prestigious than Linux. It is / was by some official definition "a Unix", though not "UNIX the trademark by AT&T".

Re: Dirty Frag: Universal Linux LPE

#138

Post by akdev1l » Thu, May 07, 2026, 10:33 PM UTC

__float wrote: post #120

ronsor wrote: post #7

Earlier quoted context omitted.

Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).

> desktop Linux doesn't (and won't for UX reasons) Can you elaborate?

A very comprehensive SELinux deployment for one.

SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.

Re: Dirty Frag: Universal Linux LPE

#139

Post by teaearlgraycold » Thu, May 07, 2026, 10:35 PM UTC

Anyone here with experience providing multi-tenant Linux systems (CI and the like), do providers usually disable kernel modules they don’t need to eliminate attack surface? Every time one of these comes out I wonder if I should be rotating every key in my GitHub CI or PaaS host. So far I haven’t seen any reports from the providers I use that they were pwned by any of these exploits.

Re: Dirty Frag: Universal Linux LPE

#140

Post by akdev1l » Thu, May 07, 2026, 10:35 PM UTC

grosswait wrote: post #24

pjmlp wrote: post #14

Earlier quoted context omitted.

Because Android is not Linux, as much as some pretend it is. In fact, given the official public APIs, Google could replace the Linux kernel with a BSD, and userspace wouldn't notice, other than rooted devices, and the OEMs themselves baking their Android distro.

It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.

The JVM has nothing to do with Android. There is no JVM running android apps.

There was Dalvik VM at one point but now it’s just the Android Runtime.