Hello, On Tue, Mar 19, 2019 at 06:28:23PM +0000, Dr. David Alan Gilbert wrote: > --- > Userfaultfd can be misued to make it easier to exploit existing use-after-free > (and similar) bugs that might otherwise only make a short window > or race condition available. By using userfaultfd to stall a kernel > thread, a malicious program can keep some state, that it wrote, stable > for an extended period, which it can then access using an existing > exploit. While it doesn't cause the exploit itself, and while it's not > the only thing that can stall a kernel thread when accessing a memory location, > it's one of the few that never needs priviledge. > > Add a flag, allowing userfaultfd to be restricted, so that in general > it won't be useable by arbitrary user programs, but in environments that > require userfaultfd it can be turned back on. The default in the patch leaves userfaultfd enabled to all users, so it may be clearer to reverse the last sentence to "in hardened environments it allows to restrict userfaultfd to privileged processes.". We can also make example that 'While this is not a kernel issue, in practice unless you also "chmod u-s /usr/bin/fusermount" there's no tangible benefit in removing privileges for userfaultfd, other than probabilistic ones by decreasig the attack surface of the kernel, but that would be better be achieved through SECCOMP and not globally.'.
