On the other hand, all of these are local exploits against userspace software, not against the kernel. So assuming your container's security model works (... which is a big assumption), the most an attacker can do is gain privileges within the container, if you have setuid-container-root binaries inside, or perhaps get arbitrary code execution or something inside the container. But they shouldn't be able to escape.
(That said, the same class of attack is in theory possible in the kernel, although the kernel tends to be way more disciplined about stack usage than userspace software.)
As we have seen with old SSL versions and Windows XP, it will be 10-15 years before the whole world is migrated onto containerized software, so this exploit should have a long, long active life.
Well, none of these exploits are container-specific. They're against setuid binaries, and it just so happens that setuid binaries in CLONE_NEWUSER containers only give you root in the container, and not real root. Containers that don't use CLONE_NEWUSER and have setuid-root binaries do give you real root, though, and I believe e.g. Docker doesn't do user namespaces by default.
Another perfectly valid way of working around the exploits is to just have an installation with no setuid binaries or file capabilities. This is difficult in a general-purpose OS that needs to be backwards compatible with traditional UNIXy things, but usually totally achievable if you're building a machine to run some specific service. (And in particular it should be really easy within a container, such that these attacks would get you neither container root nor host root.)
A contained-process-to-actual-root exploit is basically either going to be an arbitrary code execution vulnerability in the kernel itself, which tends to be referred to as something more dramatic as "local root", or a logic flaw in the container security mechanisms of the kernel itself.
Well yeah, the intended reading would be "if you're not running in a (user-namespaced) container, container root is local root". Maybe "namespace root" is a better term, though, where it's clear what it means if you're running in the init namespace.
It seems to me that "local root" is quite commonly used for kernel code execution vulnerabilities. There's also the possibility of a flaw in a service running in the init namespace that is exposed to the container.
(That said, the same class of attack is in theory possible in the kernel, although the kernel tends to be way more disciplined about stack usage than userspace software.)