- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
You must log in or # to comment.
😂😂😂
Good news. One fewer zero-day.
there is more where that came from https://xcancel.com/IntCyberDigest/status/2053802477019906058
If this is quickly solved, there is nothing to worry about
Sorry if my english is bad
Same workaround works here as with dirty frag. Just disable those kernel modules.
Maybe the solution is to just, delete a bunch of kernel modules.
How many of them are actually important anyway?
Unless you deliberately set out to compile a minimalistic custom kernel, less than half of them. Problem is, you may not be able to easily tell which half.
I’m sure removing the root user will prevent all escalation exploits. Can’t get root if there is no root!
/j
deleted by creator
Ah shit, here we go again.
what’s a scenario where you could suffer from this vulnerability?
if somebody already has access to your machine, but doesn’t have root privileges
It’s frustrating that there isn’t much of an effort to turn Linux into more of a microkernel. Instead the kernel just keeps getting bigger with even more subsystems and modules that can be exploited.
Systems built on microkernels exist, you know. See Redox.
https://redox-os.org/A microkernel wouldn’t be that useful without a stable module interface, which won’t be coming anytime soon.
There is at least already a userspace PCIe API. And USB and so on.
apparmor ftw
Fuck it, taking my home server offline for a while.
Mainly because of the nginx RCE
The Pitt IT department approves
I think you might be able to deactivate this one by turning off XFRM support in a custom-configured kernel, at the cost of losing some types of tunneling. Not going to actually test that, though.
Scarry! Uoi guys on windows better stay away…ohhh privilege!
