{"uuid": "5e9c3f17-4570-484f-9113-fab5ca85b815", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "title": "Deny alg_socket to Containers with SELinux to Mitigate CVE\u20112026\u201131431", "description": "[Original blog post](https://blog.feistel.party/2026/04/30/deny-alg-socket-to-containers-with-selinux-to-mitigate-cve-2026-31431.html)\n\n# Deny alg_socket to Containers with SELinux to Mitigate CVE\u20112026\u201131431 | Blog\u2022Feistel\u2022Party\n[CVE-2026-31431 or \u201cCopy Fail\u201d](https://xint.io/blog/copy-fail-linux-distributions) is a bug in the Linux kernel\u2019s implementation of the AF\\_ALG socket type that exposes the kernel\u2019s crypto subsystem to unprivileged userspace. Because most applications don\u2019t use this and there is a risk of container escape, it makes sense to deny access.\n\nIn the example below, I\u2019m using the `fish` shell with an SELinux userspace release after 3.6 which is when support for deny rules was added.\n\nopc@sparkling ~\\&gt; \\# remove rule for testing  \nopc@sparkling ~\\&gt; sudo semodule \\-r psub-container-alg  \nlibsemanage.semanage\\_direct\\_remove\\_key: Removing last psub-container-alg module (no other psub-container-alg module exists at another priority).  \nopc@sparkling ~\\&gt; sudo podman run \\-ti \\--rm alpine/openssl engine \\-t \\-c \\-vv afalg  \n(afalg) AFALG engine support  \n\\[AES-128-CBC, AES-192-CBC, AES-256-CBC\\]  \n\u00a0\u00a0\u00a0\u00a0\\[ available \\]  \nopc@sparkling ~\\&gt; sudo semodule \\-i (sesearch \\-A \\-s container\\_ \\-rs \\-c alg\\_socket \\-p create | egrep \\-v unconfined | sed 's/^allow/\\\\(deny/; s/:/ \\\\(/; s/{/\\\\(/; s/};/)))/' | psub \\-s \\-container-alg.cil)  \nopc@sparkling ~\\&gt; sudo podman run \\-ti \\--rm alpine/openssl engine \\-t \\-c \\-vv afalg  \n20DD97B0FFFF0000:error:4000006D:lib(128)::reason(109):engines/e\\_afalg.c:882:  \n20DD97B0FFFF0000:error:1300006D:engine routines:dynamic\\_load:init failed:crypto/engine/eng\\_dyn.c:498:  \n20DD97B0FFFF0000:error:13000074:engine routines:ENGINE\\_by\\_id:no such engine:crypto/engine/eng\\_list.c:470:id=afalg  \nopc@sparkling ~ \\[1\\]\\&gt; \\# :)  \nopc@sparkling ~ \\[1\\]\\&gt; \u00a0\n\n### Alternative Mitigations\n\n[Red Hat suggests](https://access.redhat.com/security/cve/cve-2026-31431) an `initcall_blacklist` in the boot arguments.\n\n[Lennart Poettering\u2019s advice for CVE-2016-8655](https://0pointer.net/blog/avoiding-cve-2016-8655-with-systemd.html) should also work for CVE\u20112026\u201131431 by using `RestrictAddressFamilies=~AF_ALG` on a per-service basis. In my testing this works for both containers and other services. [R-fx Networks pairs](https://www.rfxn.com/research/copyfail-cve-2026-31431) this with `SystemCallArchitectures=native`.\n\nuser@serv ~\\&gt; sudo systemd-run \\--pty \\--wait \\--collect \u00a0podman run \\-ti \\--rm alpine/openssl engine \\-t \\-c \\-vvv afalg  \nRunning as unit: run-u3914.service  \nPress ^\\] three times within 1s to disconnect TTY.  \n(afalg) AFALG engine support  \n\\[AES-128-CBC, AES-192-CBC, AES-256-CBC\\]  \n\u00a0\u00a0\u00a0\u00a0\\[ available \\]  \nFinished with result: success  \nMain processes terminated with: code=exited/status=0  \nService runtime: 548ms  \nuser@serv ~\\&gt; sudo systemd-run \\--pty \\--wait \\--collect \\-p 'RestrictAddressFamilies=~AF\\_PACKET AF\\_ALG' podman run \\-ti \\--rm alpine/openssl engine \\-t \\-c \\-vvv afalg  \nRunning as unit: run-u3923.service  \nPress ^\\] three times within 1s to disconnect TTY.  \n280B94F7067F0000:error:4000006D:lib(128)::reason(109):engines/e\\_afalg.c:882:  \n280B94F7067F0000:error:1300006D:engine routines:dynamic\\_load:init failed:crypto/engine/eng\\_dyn.c:498:  \n280B94F7067F0000:error:13000074:engine routines:ENGINE\\_by\\_id:no such engine:crypto/engine/eng\\_list.c:470:id=afalg  \nFinished with result: exit-code  \nMain processes terminated with: code=exited/status=1  \nService runtime: 563ms  \nuser@serv ~ \\[1\\]\\&gt; sudo systemd-run \\--pty \\--wait \\--collect openssl engine \\-t \\-c \\-vvv afalg  \nRunning as unit: run-u3932.service  \nPress ^\\] three times within 1s to disconnect TTY.  \n(afalg) AFALG engine support  \n\\[AES-128-CBC, AES-192-CBC, AES-256-CBC\\]  \n\u00a0\u00a0\u00a0\u00a0\\[ available \\]  \nFinished with result: success  \nMain processes terminated with: code=exited/status=0  \nService runtime: 8ms  \nuser@serv ~\\&gt; sudo systemd-run \\--pty \\--wait \\--collect \\-p 'RestrictAddressFamilies=~AF\\_PACKET AF\\_ALG' openssl engine \\-t \\-c \\-vvv afalg  \nRunning as unit: run-u3935.service  \nPress ^\\] three times within 1s to disconnect TTY.  \n139718332651328:error:8006406D:lib(128):func(100):reason(109):engines/e\\_afalg.c:800:  \n139718332651328:error:260B606D:engine routines:dynamic\\_load:init failed:crypto/engine/eng\\_dyn.c:485:  \n139718332651328:error:2606A074:engine routines:ENGINE\\_by\\_id:no such engine:crypto/engine/eng\\_list.c:334:id=afalg  \nFinished with result: exit-code  \nMain processes terminated with: code=exited/status=1  \nService runtime: 7ms  \nuser@serv ~ \\[1\\]\\&gt; \u00a0\n\n### Questions about SELinux\n\n#### Why was support for deny rules only added to the SELinux userspace in 2023?\n\n#### Why is the output of `sesearch` so dissimilar to the input of `semanage` ?\n\n#### What is the purpose of `allow unconfined_domain_type domain:alg_socket` and does leaving this rule alone ruin the mitigation?\n\nopc@sparkling ~\\&gt; seinfo \\-a unconfined\\_domain\\_type \\-x | grep \\-E '(contain|^\\\\w|^\\\\s{3})\\\\w'  \nType Attributes: 1  \n\u00a0\u00a0attribute unconfined\\_domain\\_type;  \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0container\\_runtime\\_t  \nopc@sparkling ~\\&gt; \u00a0\n\nThis relates to `container_runtime_t`. This is [for privileged containers in rootless mode](https://www.redhat.com/en/blog/privileged-flag-container-engines) and [for the container management engine itself](https://criu.org/Security_Enhanced_Linux). So it\u2019s probably OK.", "description_format": "markdown", "vulnerability": "CVE-2026-31431", "creation_timestamp": "2026-05-01T12:15:18.046173+00:00", "timestamp": "2026-05-01T12:15:18.046173+00:00", "related_vulnerabilities": ["CVE-2016-8655", "CVE-2026-31431"], "meta": [{"tags": ["vulnerability:information=remediation"]}], "author": {"login": "adulau", "name": "Alexandre Dulaunoy", "uuid": "c933734a-9be8-4142-889e-26e95c752803"}}
