CVE-2026-31431: Copy Fail vs. rootless containers

Post by nubinetwork » Tue, May 05, 2026, 9:36 AM UTC

jeroenhd wrote: post #35

amluto wrote: post #8

Sigh. 1. I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. 2. The write-to-RO-page-cache primitive STILL WORKED! It’s just that the particular exploit used had no meaningful effect in the already-root-in-a-container context. If you think you are safe, you’re probably wrong. All you need to make a new exploit is an fd representing something that you aren’t supposed t…

> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. I see a lot of projects blocking those sockets in containers as a response to this exploit, but it seems rather strange to me. We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? It's a rather weird default to use. It's not like we're mass…

Post by PunchyHamster » Tue, May 05, 2026, 9:50 AM UTC

nubinetwork wrote: post #41

jeroenhd wrote: post #35

Earlier quoted context omitted.

> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. I see a lot of projects blocking those sockets in containers as a response to this exploit, but it seems rather strange to me. We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? It's a rather weird default to use. It's not like we're mass…

> We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? To my knowledge, not many things were using the in-kernel code anyways, the recommended way is to use userland tools... It's optional for openssl, systemd apparently needs it, but deleting the module from one of my systems didn't cause any issues. /shrug

Post by e12e » Tue, May 05, 2026, 9:53 AM UTC

jeroenhd wrote: post #35

amluto wrote: post #8

Sigh. 1. I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. 2. The write-to-RO-page-cache primitive STILL WORKED! It’s just that the particular exploit used had no meaningful effect in the already-root-in-a-container context. If you think you are safe, you’re probably wrong. All you need to make a new exploit is an fd representing something that you aren’t supposed t…

> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. I see a lot of projects blocking those sockets in containers as a response to this exploit, but it seems rather strange to me. We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? It's a rather weird default to use. It's not like we're mass…

Post by Retr0id » Tue, May 05, 2026, 9:56 AM UTC

cpach wrote: post #42

walletdrainer wrote: post #23

This feels LLM generated, lots of emdashes and even more text around a completely false premise.

What is the false premise in the article?

Post by PunchyHamster » Tue, May 05, 2026, 9:59 AM UTC

washbasin wrote: post #3

Please post a tl;dr at the top or even in the subject. Many of us are scrambling to patch/reboot our **.

    echo -e 'install algif_aead /bin/false\n' > /etc/modprobe.d/disable-algif.conf