Namespaces are a visibility control. They restrict what a process can see, and they do not hand each container its own copy of the kernel to run code against; every process, containerized or not, ends up in the same kernel space [6]. So the syscall issued from inside a pod and the syscall issued from a shell on the node arrive at the same code. Throwing the container away afterwards cleans up the process and does nothing about kernel memory that has already been overwritten.
For the escape described in the dev.to post to apply to your fleet, one thing has to be true: the container's kernel is the node's kernel [6]. The post draws that boundary itself, contrasting containers with hypervisor-based VMs, where the guest kernel is separated from the host by the hypervisor [7]. Where a workload's kernel sits behind a hypervisor, the post's argument does not reach it on its own terms [17]. Where it does not, the node's kernel state is the only variable that matters, and the post never names a fixed version, a vendor advisory, or an affected-version range [15]. Until one of those exists, the argument stays structural rather than actionable.
The severity number has the same problem. It arrives without a vector string [15], so it does not tell you what access the score assumed, and on a shared-kernel node that is the whole question.
Then there is the fix the author actually shipped. The post reports adding a kernel-level toggle that denies unprivileged processes the ability to create a new user namespace, verified as an unprivileged user with `unshare -U -r` [14]. The chain the same post describes has two preconditions: unprivileged code execution from some foothold, and the ability to create a UDP socket, after which IPv6 fragment handling is abused to overwrite kernel memory and land on the host as root [8][9]. The toggle addresses neither of those two preconditions [16]. It would cover the path if public exploit code needed a user namespace to reach the fragmentation code, and the post does not say that it does.
The precondition that does match is socket creation, and the post's own parenthetical is the interesting part: almost no processes are prevented from creating a UDP socket [10]. That is the setting this story depends on. Any workload that speaks the network needs sockets, so the seccomp-shaped answer is unavailable to most of the things running on a node, which leaves the kernel version underneath them.
The second-layer claim is worth reading carefully too. According to the post, the attack rewrites trust structures inside the kernel and takes SELinux-style mandatory access control down with it, so "we're containerized" and "we have SELinux enforcing" stop being two independent lines of defence at the same moment [11]. The post offers only that assertion, with no evidence to confirm it. It is the kind of claim that follows from arbitrary kernel memory writes, and it is also the kind of claim you would want an advisory to confirm before you rebuild a control model around it.
The honest part is this: the author, an independent developer who builds a Linux defensive tool called RoamSwitch, went back through his own code and found that every protection he had was watching inbound packets and filesystem writes, with nothing looking at a process already inside the box calling into the kernel [12][13]. That failure mode is the same one the post attributes to infrastructure-as-code, where a developer builds a Dockerfile in CI and ships to a managed platform without touching the kernel at all [19]. All of this comes from one first-person post that neither links nor quotes the catalog entry [18].
