git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
Result: dirtyfrag: failed (rc=3)
Good news!151–160 of 370 posts
git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
Result: dirtyfrag: failed (rc=3)
Good news!I'm curious what broke the embargo. Did it leak or did a third party find it independently?
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 pretend vulnerability is not leaked until the "official" message in the mailing list is sent.
This approach might have been defensible before, but in LLM era, when people have automated pipelines feeding diffs straight from the mailing lists to SotA models asking to identify probable security issues fixed by those, it is both stupid and dangerous.
Linux is a single user system and should be treated as such. Run your services as root. Don't rely on unix user primitives for security.
This carries the same energy as "People will break into your car no matter what, so just leave your doors unlocked."
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 alrea…
Hell, GitHub Actions would do.
Earlier quoted context omitted.
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.
It's not any different from putting an always-running network service behind socket activation instead. The security boundary/risk is nearly identical between the two.
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.