Post #2244852
2026-05-07 21:34 UTC
Replies (5)
-
@valpackett@social.treehouse.systems 2026-05-07 21:37
@hailey@hails.org AF_NETLINK, AF_RXRPC and AF_ALG are used in the (combined) exploit, even. uhh podman/pasta needs netlink for itself but it sure shouldn't expose netlink to random programs inside of the container!
-
@whitequark@social.treehouse.systems 2026-05-07 21:43
@hailey@hails.org unfortunately my other option for CI is VMs... but I was already building in that direction before the disclosures
-
@freya@social.highenergymagic.net 2026-05-07 21:49
@hailey@hails.org my recommendation for container users: use gVisor or Kata Containers to isolate each container ot prevent this kind of thing
-
@dalias@hachyderm.io 2026-05-07 22:01
@hailey@hails.org AFAICT AF_NETLINK has nothing to do with the vuln. It's just the underlying mechanism for a lot of normal things. In this case user namespaces would even be a more plausible culprit for allowing users to reach the vulnerable code than AF_NETLINK is. But the culprit is splice and all the gratuitous zerocopy stuff you don't need unless you're trying to serve a video streaming platform with millions of users.
-
@rose@snac.pinkro.se 2026-05-08 00:22
AF_NETLINK absolutely isn't obscure, the kernel uses it for communicating with userspace applications, such as hardware uevents, which means disabling netlink breaks the device manager what the LPE really exploited was NETLINK_XFRM, a type of netlink message the kernel uses for IPsec