| - |
A security issue was found in QEMU. The new '-o xattrmap' option in virtiofsd-5.2.0 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. |
| + |
A security issue was found in in the virtio-fs shared file system daemon (virtiofsd) of QEMU. Virtio-fs is meant to share a host file system directory with a guest virtual machine. The new 'xattrmap' option may cause the 'security.capability' xattr in the guest to not drop on file write, potentially leading to a modified, privileged executable in the guest. In rare circumstances, this flaw could be used by a malicious user to elevate their privileges within the guest. |
| + |
|
| + |
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. There's a suspicion the flaw could be reproduced with the default option '-o cache=auto' as well. |
| + |
|
| + |
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. |