** Also affects: linux (Ubuntu Precise)
Importance: Undecided
Status: New
** No longer affects: linux (Ubuntu Precise)
** Also affects: linux-lts-trusty (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: linux-lts-trusty (Ubuntu Precise)
Importance: Undecided
Status: New
** Changed in: linux-lts-trusty (Ubuntu Trusty)
Status: New => Invalid
** Changed in: linux (Ubuntu Precise)
Status: New => Invalid
** Changed in: linux-lts-trusty (Ubuntu Precise)
Status: New => Triaged
--
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-lts-trusty” package in Ubuntu:
New
Status in “linux” source package in Precise:
Invalid
Status in “linux-lts-trusty” source package in Precise:
Triaged
Status in “linux” source package in Trusty:
Fix Committed
Status in “linux-lts-trusty” source package in Trusty:
Invalid
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
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
