logoalt Hacker News

loufetoday at 10:51 AM3 repliesview on HN

In what way is it "not a special bug"? It's a publicly known root access from RCE exploit. Those cannot be a dime a dozen. I'm sure it's especially interesting for any shared hosting services which might be affected, and could be delayed. I could find any places running containered services and exfiltrate secrets parallel services, no?

What constitutes "special" for you, out of curiosity? Something chaining with a hypervisor exploit?


Replies

IshKebabtoday at 7:17 PM

They're not dime a dozen exactly but LPE bugs in Linux (and common Linux distros) are easily common enough that nobody sane relies on user isolation as a serious security boundary.

Clouds use VMs as the security barrier, which is also not always 100% perfect, but is much better.

It could be useful as part of an exploit chain but generally once you've got to local code execution it's not going to be difficult to get further.

A "special" bug would be something that defeats a security barrier that people actually use, e.g. something that works remotely, or as you say - a hypervisor hack.

bjackmantoday at 1:14 PM

It's not RCE it's an LPE in an obscure corner of the kernel attack surface that no sensible application depends on. They are absolutely a dime a dozen.

Even just in AF_ALG there have been several such vulns fixed in 2026 already. Kernel wide probably hundreds. It's true that most of them will be harder to exploit than this one but that just means you need to prompt your AI a bit harder to get an exploit. (To be fair, in a lot of cases it's gonna be hard to escalate privs without crashing the machine).

Ubuntu has userns restrictions now which takes away the main sources of LPEs (random qdiscs, nftables, all that garbage) but there are still huge numbers of these vulns. This is why platforms that do native untrusted code executions have extreme sandboxing. Note Android and ChromeOS aren't affected coz they already knew this code was broken and hide it from unpriv workloads.

You can't run untrusted code on Linux without either a very very carefully designed sandboxing layer (like Android/ChromeOS) or virtualization. copy.fail is just one among tens of thousands of reasons for this, and it's a pretty uninteresting one at that.

What is "special" depends on your usecase but for my job it's mostly about stuff that's exposed to KVM guests. Biggest source of concerning vulns for us is probably vhost. I expect there are also lots of undiscovered and scary vulns in places like virtiofs, vfio, DAX, and wherever we do device passthrough.

> I could find any places running containered services and exfiltrate secrets parallel services, no?

Yes. Regardless of copy.fail. Cloud providers don't do that without a VM layer. (If yours does, you need to switch).

show 1 reply