So from a reading of the advisory and pull request, this seems to affect a specific set of scenarios, where a malicious image is running (attacker has gained access either to the running container, or compromised the image before distribution) and then a process goes to copy data out of the running container (for example by using docker cp).
Not sure if there are other scenarios where this would hit as well.
One to be aware of, but as with most vulnerabilities, good to understand how it can be exploited, when you're assessing mitigations...
Would an arbitrary image upload alone allow exploitation of this, or would it require an operation on the host along the lines of a 'docker cp' as well?
The only currently known and exploitable API is with `docker cp`, but FollowSymlinkInScope is used all over the place. Unfortunately, fixing FollowSymlinkInScope requires redesigning the API and then redesigning all the callers so they stop passing around path strings blindly and instead pass around handles (which are O_PATH fds).
But, as I mentioned in TFA, the plan is to rework https://github.com/cyphar/filepath-securejoin to have a sane API that detects attacks on older kernels while using the new kernel bits (once merged).
Not sure if there are other scenarios where this would hit as well.
One to be aware of, but as with most vulnerabilities, good to understand how it can be exploited, when you're assessing mitigations...