28.02.2013 13:12, Aneesh Kumar K.V wrote:
> Michael Tokarev <m...@tls.msk.ru> writes:
>
>> When guest tries to chmod a block or char device file over 9pfs,
>> the qemu process segfaults.
>>
>> On host:
>> qemu-system-x86_64 -virtfs
>> local,path=/dev,security_model=mapped-file,mount_tag=tag
>>
>> On guest:
>> mount -t 9p -o trans=virtio tag /mnt
>> chmod 0777 /mnt/tty
>
> any specific reason why you are trying 9p .u ?
Sorry? What _is_ "9p .u" ? :)
[]
>> Maybe the buffer (extension->data) should be passed to it instead of
>> the whole structure (extension)? Or the check be extended (or,
>> since this function isn't called from any other place, _replaced_) to
>> test for non-NULL ->data too?
>>
>
> Thanks for the detailed analysis. Something like below ?
>
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index f526467..073067f 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -659,7 +659,7 @@ static mode_t v9mode_to_mode(uint32_t mode, V9fsString
> *extension)
> ret |= S_IFIFO;
> }
> if (mode & P9_STAT_MODE_DEVICE) {
> - if (extension && extension->data[0] == 'c') {
> + if (extension->size && extension->data[0] == 'c') {
> ret |= S_IFCHR;
> } else {
> ret |= S_IFBLK;
>
Yeah, that looks much saner. And it obviously works, just
like testing ext->data to be non-null.
It has been this way since about beginning (as in, for example,
1.1 version of qemu is also affected), and probably is a good
candidate for -stable too.
Reviewed-By: Michael Tokarev <m...@tls.msk.ru>
Thank you!
/mjt
