The new '-o xattrmap' option in virtiofsd causes some cases in which the 'security.capability' xattr in the guest isn't dropped on write, potentially leading to a modified privileged executable. For the problem to happen virtiofsd needs to be running with '-o xattr' and '-o xattrmap' (to enable and rename xattrs, respectively). The problem only occurs if 'security.capability' is one of the xattrs that is being renamed. Different caching modes cause different guest behavior: '-o cache=none' makes the issue easy to reproduce but it may also occur with '-o cache=auto' as well. Virtiofsd 'xattrmap' feature in QEMU 5.2: https://gitlab.com/virtio-fs/qemu/-/commit/6084633dff3a05d6317 Upstream fix: https://git.qemu.org/?p=qemu.git;a=commit;h=e586edcb410543768ef009eaa22a2d9dd4a53846
Acknowledgments: Name: David Alan Gilbert (Red Hat)
Patch posted to qemu-devel: https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01244.html and pull sent upstream.
Created qemu tracking bugs for this issue: Affects: fedora-all [bug 1935089]
Merged upstream qemu: e586edcb410543768ef009eaa22a2d9dd4a53846
Note that the impact of this flaw is limited by the fact that xattrmap is a recent feature that's little used so far. Additionally, unprivileged users shouldn't be granted write permission on privileged executables in the first place.
Statement: This issue does not affect the versions of QEMU as shipped with Red Hat Enterprise Linux and RHEL Advanced Virtualization, as they did not include support for the 'xattrmap' feature.
External References: https://www.openwall.com/lists/oss-security/2021/03/08/1