@hlieberman, the researchers imply container escape == root access on the target host, that is why they used a setuid binary in order to demonstrate the whole exploit. What this article mentions is that while the container escape (as in the ability to modify a binary in memory that may be shared across multiple containers) is still present gaining root in the underlying host doesn't happen.

@isityettime, the vulnerability happens not because of file contents being modified on disk (think of a base image that is shared across multiple CI builds) rather because a binary in one base image shares the same inode (and thus the same address space in memory as an optimization) as the same binary in another container, meaning container B will execute a poisoned binary and that's where the "container escape" happens.

That's true... for the exploit demo that they released. The primitive that underlies the exploit, however -- a page cache write -- can easily bypass the container boundary. One only needs to hook an executable which is also present in the host.

Please reply instead of (or in addition to) tagging the user you're replying to.