Hmm… so this dates back quite long ago unfortunately, I had basically
forgotten about this bug report as I had opened it while just
experimenting with qemu.
To the best of my recollection, this was happening with a NixOS, either
16.09, 17.03 or unstable, at an update that was probably within 0-2
m
On 05/24/2017 10:54 AM, Greg Kurz wrote:
> On Wed, 24 May 2017 00:59:29 +0200
> Leo Gaspard wrote:
>
>> On 05/23/2017 04:32 PM, Greg Kurz wrote:
>>> v2: - posted patch for CVE-2017-7493 separately
>>> - other changes available in each patch changelog
>>
On 05/23/2017 07:13 PM, Eric Blake wrote:> We have to block
VIRTFS_META_DIR at any depth in the hierarchy, but
> can/should we change the blocking of VIRTFS_META_ROOT_FILE to only
> happen at the root directory, rather than at all directories? On the
> other hand, if you can simultaneously map /pa
On 05/23/2017 04:32 PM, Greg Kurz wrote:
> v2: - posted patch for CVE-2017-7493 separately
> - other changes available in each patch changelog
>
> Leo,
>
> If you find time to test this series, I'll gladly add your Tested-by: to
> it before merging.
Just tested with a base of 2.9.0 with patc
Greg,
I just tested on 2.9.0 with the 5 patches applied, and it appears to
work on my setup, thanks!
Just a side note: .virtfs_metadata_root is set as u=rwx on the host file
system (the "ret = fchmod(map_fd, 0700);" line in patch 4 I guess),
while u=rw would be more appropriate, I think.
Thank y
Public bug reported:
With
-virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2"
in the qemu command line,
shared2 on /mnt/testbis type 9p
(rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144)
in the guest mount points, and
tmpfs on /tmp type tmpfs (rw,nos
Hmm, actually it looks like a kernel in kernel panic always takes 100%
CPU (just got another unrelated one), so I guess it's not necessarily a
qemu bug but can arise from anywhere in the stack. I'm marking the bug
as invalid as a consequence.
** Changed in: qemu
Status: New => Invalid
--
Oh, I forgot to mention: it first worked for some time, then in the
middle of a shell session running over a screen
/var/lib/vm/consoles/nginx/screen from the outer VM (socat-linked to
/var/lib/vm/consoles/nginx/socket.unix to provide a predictable pty
link), the 9pfs stopped returning any data, an
Public bug reported:
tl;dr: A virtfs read fails. The init being on this virtfs (mounted by
the initrd), the linux kernel guest is unable to boot, and kernel
panics. The fact that qemu still takes 100%cpu after the kernel panic
makes me think it's a qemu bug.
Here is the setup (some hashes replace
