kernel-packages team mailing list archive

[Bruce Lucas <bruce.lucas@xxxxxxxxxxx>]

Thanks Chris.

I take it from the other thread that bubbling the setting up from the lower
layer to the dm-* layer won't be possible.

Do you know if this patch will fix it for ESXi as well as for the VMWare
desktop products? I don't have access to ESXi, but the issue was originally
reported to us by a customer running ESXi. I could ask them to try the
patched kernel, but maybe we could do a simpler check first. Is there a way
to determine the vendor id for their virtual SCSI disks on a running system
so we can verify that the vendor id is the same?

Thanks,
Bruce

On Wed, Sep 24, 2014 at 10:00 AM, Chris J Arges <1371591@xxxxxxxxxxxxxxxxxx>
wrote:

> https://lkml.org/lkml/2014/9/23/509
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1371591
>
> Title:
>   file not initialized to 0s under some conditions on VMWare
>
> Status in “linux” package in Ubuntu:
>   In Progress
> Status in “linux” source package in Trusty:
>   New
>
> Bug description:
>   Under some conditions, after fallocate() the file is observed not to
>   be completely initilized to 0s: some 4KB pages have left-over data
>   from previous files that occupied those pages. Note that in addition
>   to causing functional problems for applications expecting files to be
>   initialized to 0s, this is a security issue because it allows data to
>   "leak" from one file to another, bypassing file access controls.
>
>   The problem has been seen running under the following VMWare-based
> virtual environments:
>   Fusion 6.0.2
>   ESXi 5.1.0
>
>   And under the following versions of Ubuntu:
>   Ubuntu 12.04, 3.11.0-26-generic
>   Ubuntu 14.04.1, 3.13.0-32-generic
>   Ubuntu 14.04.1, 3.13.0-35-generic
>
>   But did not reproduce under the following version:
>   Ubuntu 10.04, 2.6.32-38-server
>
>   The problem reproduced under LVM, but did not reproduce without LVM.
>
>   I reproduced the problem as follows under VMWare Fusion:
>   set up custom VM with default disk size (20 GB) and memory size (1 GB)
>   attach Ubuntu 14.04.1 ISO to CDROM, set it as boot device, boot up
>   select all defaults during installation _including_ LVM
>   install gcc
>   unpack the attached repro.tgz
>   run repro.sh
>
>   what it does:
>   * fills the disk with a file containing bytes of 0xcc then deletes it
>   * repeatedly runs the repro program which creates two files and accesses
> them in a certain pattern
>   * checks the file f0 with hexdump; it should contain all 0s, but if
> pages 0x1000-0x7000 contain 0xcc you have reproduced the problem
>
>   If the problem does not appear to reproduce, please try waiting a bit
>   and checking the f0 files with hexdump again. This behavior was
>   observed by a customer reproducing the problem under ESXi. I since
>   added an sync after the running the repro binary which I think will
>   fix that.
>
>   If you still can't reproduce the problem please let me know if there's
>   anything I can do to help. For example can we trace the disk accesses
>   at the SCSI level to verify whether the appropriate SCSI commands are
>   being sent? This may help determine whether the problem is in Linux or
>   in VMWare.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+subscriptions
>

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1371591

Title:
  file not initialized to 0s under some conditions on VMWare

Status in “linux” package in Ubuntu:
  In Progress
Status in “linux” source package in Trusty:
  New

Bug description:
  Under some conditions, after fallocate() the file is observed not to
  be completely initilized to 0s: some 4KB pages have left-over data
  from previous files that occupied those pages. Note that in addition
  to causing functional problems for applications expecting files to be
  initialized to 0s, this is a security issue because it allows data to
  "leak" from one file to another, bypassing file access controls.

  The problem has been seen running under the following VMWare-based virtual environments:
  Fusion 6.0.2
  ESXi 5.1.0

  And under the following versions of Ubuntu:
  Ubuntu 12.04, 3.11.0-26-generic
  Ubuntu 14.04.1, 3.13.0-32-generic
  Ubuntu 14.04.1, 3.13.0-35-generic

  But did not reproduce under the following version:
  Ubuntu 10.04, 2.6.32-38-server

  The problem reproduced under LVM, but did not reproduce without LVM.

  I reproduced the problem as follows under VMWare Fusion:
  set up custom VM with default disk size (20 GB) and memory size (1 GB)
  attach Ubuntu 14.04.1 ISO to CDROM, set it as boot device, boot up
  select all defaults during installation _including_ LVM
  install gcc
  unpack the attached repro.tgz
  run repro.sh

  what it does:
  * fills the disk with a file containing bytes of 0xcc then deletes it
  * repeatedly runs the repro program which creates two files and accesses them in a certain pattern
  * checks the file f0 with hexdump; it should contain all 0s, but if pages 0x1000-0x7000 contain 0xcc you have reproduced the problem

  If the problem does not appear to reproduce, please try waiting a bit
  and checking the f0 files with hexdump again. This behavior was
  observed by a customer reproducing the problem under ESXi. I since
  added an sync after the running the repro binary which I think will
  fix that.

  If you still can't reproduce the problem please let me know if there's
  anything I can do to help. For example can we trace the disk accesses
  at the SCSI level to verify whether the appropriate SCSI commands are
  being sent? This may help determine whether the problem is in Linux or
  in VMWare.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+subscriptions