| 2014-09-19 13:03:38 |
Leann Ogasawara |
bug |
|
|
added bug |
| 2014-09-19 13:30:09 |
Brad Figg |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2014-09-19 13:42:56 |
Leann Ogasawara |
linux (Ubuntu): importance |
Undecided |
Critical |
|
| 2014-09-19 13:49:44 |
Bruce Lucas |
description |
To be filled in... |
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 _except_ 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. |
|
| 2014-09-19 13:49:59 |
Chris J Arges |
linux (Ubuntu): assignee |
Canonical Kernel Team (canonical-kernel-team) |
Chris J Arges (arges) |
|
| 2014-09-19 13:50:32 |
Bruce Lucas |
summary |
FS Corruption with Ubuntu and VMWare |
file not initialized to 0s under some conditions on VMWare |
|
| 2014-09-19 13:52:40 |
Bruce Lucas |
attachment added |
|
reproducer https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+attachment/4208902/+files/repro.tgz |
|
| 2014-09-19 14:22:25 |
Tim Gardner |
bug |
|
|
added subscriber Tim Gardner |
| 2014-09-19 14:36:10 |
Dan Pasette |
bug |
|
|
added subscriber Dan Pasette |
| 2014-09-19 14:46:09 |
Bruce Lucas |
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 _except_ 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. |
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. |
|
| 2014-09-19 14:47:15 |
Bruce Lucas |
attachment added |
|
sample repro script output https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+attachment/4208971/+files/repro.txt |
|
| 2014-09-19 14:53:12 |
Bruce Lucas |
bug |
|
|
added subscriber Bruce Lucas |
| 2014-09-19 15:10:17 |
Chris J Arges |
linux (Ubuntu): status |
Incomplete |
In Progress |
|
| 2014-09-19 15:36:25 |
Leann Ogasawara |
information type |
Public |
Public Security |
|
| 2014-09-19 15:49:37 |
Joseph Salisbury |
tags |
|
kernel-da-key |
|
| 2014-09-19 16:05:30 |
Chris J Arges |
tags |
kernel-da-key |
kernel-bug-exists-upstream kernel-da-key |
|
| 2014-09-19 16:05:41 |
Chris J Arges |
nominated for series |
|
Ubuntu Trusty |
|
| 2014-09-19 16:05:41 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Trusty) |
|
| 2014-09-19 23:24:48 |
AK |
bug |
|
|
added subscriber Anil Kumar |
| 2014-09-29 08:28:07 |
Andy Whitcroft |
linux (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2014-09-29 08:28:13 |
Andy Whitcroft |
linux (Ubuntu Trusty): status |
New |
Fix Committed |
|
| 2014-10-02 05:13:53 |
Launchpad Janitor |
linux (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2014-10-10 15:15:55 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-proposed/linux-lts-trusty |
|
| 2014-10-10 19:30:48 |
Arvind Kumar |
attachment added |
|
0001-Do-not-silently-discard-WRITE_SAME-requests.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+attachment/4230953/+files/0001-Do-not-silently-discard-WRITE_SAME-requests.patch |
|
| 2014-10-10 19:32:25 |
Arvind Kumar |
bug |
|
|
added subscriber Petr Vandrovec |
| 2014-10-10 19:33:02 |
Arvind Kumar |
bug |
|
|
added subscriber Swapneel Kekre |
| 2014-10-10 19:37:20 |
Arvind Kumar |
bug |
|
|
added subscriber Darius Davis |
| 2014-10-10 20:51:18 |
Arvind Kumar |
bug |
|
|
added subscriber Richard Harry |
| 2014-10-10 21:34:40 |
Petr Vandrovec |
attachment added |
|
Do not ignore WRITE_SAME failures https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+attachment/4231085/+files/0001-Do-not-silently-discard-WRITE_SAME-requests.patch |
|
| 2014-10-10 22:33:29 |
Chris J Arges |
linux (Ubuntu): status |
Fix Released |
In Progress |
|
| 2014-10-10 22:33:32 |
Chris J Arges |
linux (Ubuntu): importance |
Critical |
High |
|
| 2014-10-11 00:27:47 |
Ubuntu Foundations Team Bug Bot |
tags |
kernel-bug-exists-upstream kernel-da-key |
kernel-bug-exists-upstream kernel-da-key patch |
|
| 2014-10-11 00:27:48 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Joseph Salisbury |
| 2014-10-14 15:08:04 |
Robert C Jennings |
nominated for series |
|
Ubuntu Precise |
|
| 2014-10-14 15:51:32 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/trusty-proposed/linux-keystone |
|
| 2014-10-16 07:05:34 |
Brad Figg |
tags |
kernel-bug-exists-upstream kernel-da-key patch |
kernel-bug-exists-upstream kernel-da-key patch verification-needed-trusty |
|
| 2014-10-16 12:31:02 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Precise) |
|
| 2014-10-16 12:31:14 |
Chris J Arges |
bug task deleted |
linux (Ubuntu Precise) |
|
|
| 2014-10-16 12:31:22 |
Chris J Arges |
bug task added |
|
linux-lts-trusty (Ubuntu) |
|
| 2014-10-16 12:31:41 |
Chris J Arges |
nominated for series |
|
Ubuntu Precise |
|
| 2014-10-16 12:31:41 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Precise) |
|
| 2014-10-16 12:31:41 |
Chris J Arges |
bug task added |
|
linux-lts-trusty (Ubuntu Precise) |
|
| 2014-10-16 12:32:01 |
Chris J Arges |
linux-lts-trusty (Ubuntu Trusty): status |
New |
Invalid |
|
| 2014-10-16 12:32:04 |
Chris J Arges |
linux (Ubuntu Precise): status |
New |
Invalid |
|
| 2014-10-16 12:32:08 |
Chris J Arges |
linux-lts-trusty (Ubuntu Precise): status |
New |
Triaged |
|
| 2014-10-16 17:55:45 |
Swapneel Kekre |
summary |
file not initialized to 0s under some conditions on VMWare |
file not initialized to 0s under some conditions |
|
| 2014-10-16 22:26:42 |
Launchpad Janitor |
linux-lts-trusty (Ubuntu): status |
New |
Confirmed |
|
| 2014-10-16 22:27:02 |
YAMAMOTO Hirotaka |
bug |
|
|
added subscriber YAMAMOTO Hirotaka |
| 2014-10-17 01:53:33 |
Kane York |
linux (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2014-10-20 13:44:00 |
Chris J Arges |
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. |
SRU Justification:
[Impact]
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.
[Test Case]
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.
[Fix]
mptfusion: enable no_write_same in scsi_host_template
commit 4089b71cc820a426d601283c92fcd4ffeb5139c2 upstream
https://lkml.org/lkml/2014/9/25/482
(Note this patch may be reverted in the future as there is active discussion upstream about a more generic fix) |
|
| 2014-10-20 13:55:57 |
Chris J Arges |
tags |
kernel-bug-exists-upstream kernel-da-key patch verification-needed-trusty |
kernel-bug-exists-upstream kernel-da-key patch verification-done-trusty |
|
| 2014-10-20 13:56:07 |
Chris J Arges |
linux (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2014-10-29 02:42:50 |
Launchpad Janitor |
linux (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2014-10-29 02:42:50 |
Launchpad Janitor |
cve linked |
|
2014-3610 |
|
| 2014-10-29 02:42:50 |
Launchpad Janitor |
cve linked |
|
2014-3611 |
|
| 2014-10-29 02:42:50 |
Launchpad Janitor |
cve linked |
|
2014-3646 |
|
| 2014-10-29 02:42:50 |
Launchpad Janitor |
cve linked |
|
2014-3647 |
|
| 2014-10-29 20:27:54 |
Launchpad Janitor |
linux-lts-trusty (Ubuntu Precise): status |
Triaged |
Fix Released |
|
| 2015-01-09 14:12:29 |
Chris J Arges |
nominated for series |
|
Ubuntu Utopic |
|
| 2015-01-09 14:12:29 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Utopic) |
|
| 2015-01-09 14:12:29 |
Chris J Arges |
bug task added |
|
linux-lts-trusty (Ubuntu Utopic) |
|
| 2015-01-09 14:13:33 |
Chris J Arges |
linux-lts-trusty (Ubuntu Utopic): status |
New |
Invalid |
|
| 2015-01-09 14:13:38 |
Chris J Arges |
linux (Ubuntu Utopic): assignee |
|
Chris J Arges (arges) |
|
| 2015-01-09 14:13:41 |
Chris J Arges |
linux (Ubuntu Utopic): status |
New |
Triaged |
|
| 2015-01-13 20:29:18 |
Chris J Arges |
linux-lts-trusty (Ubuntu Precise): status |
Fix Released |
In Progress |
|
| 2015-01-13 20:29:22 |
Chris J Arges |
linux (Ubuntu Utopic): status |
Triaged |
In Progress |
|
| 2015-01-13 20:29:25 |
Chris J Arges |
linux-lts-trusty (Ubuntu Precise): assignee |
|
Chris J Arges (arges) |
|
| 2015-01-13 20:29:27 |
Chris J Arges |
linux (Ubuntu Trusty): assignee |
|
Chris J Arges (arges) |
|
| 2015-01-13 20:29:29 |
Chris J Arges |
linux (Ubuntu Trusty): status |
Fix Released |
In Progress |
|
| 2015-01-13 20:29:31 |
Chris J Arges |
linux (Ubuntu): status |
Fix Released |
In Progress |
|
| 2015-01-13 20:29:33 |
Chris J Arges |
linux (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2015-01-13 20:29:34 |
Chris J Arges |
linux (Ubuntu Utopic): importance |
Undecided |
High |
|
| 2015-01-13 20:29:36 |
Chris J Arges |
linux-lts-trusty (Ubuntu Precise): importance |
Undecided |
High |
|
| 2015-01-31 19:37:55 |
Mathew Hodson |
tags |
kernel-bug-exists-upstream kernel-da-key patch verification-done-trusty |
kernel-bug-exists-upstream kernel-bug-exists-upstream-v3.17-rc1 kernel-da-key patch verification-done-trusty |
|
| 2015-01-31 19:43:05 |
Mathew Hodson |
cve unlinked |
2014-3610 |
|
|
| 2015-01-31 19:43:19 |
Mathew Hodson |
cve unlinked |
2014-3611 |
|
|
| 2015-01-31 19:43:35 |
Mathew Hodson |
cve unlinked |
2014-3646 |
|
|
| 2015-01-31 19:43:47 |
Mathew Hodson |
cve unlinked |
2014-3647 |
|
|
| 2015-05-21 10:24:16 |
Andy Whitcroft |
linux (Ubuntu Utopic): status |
In Progress |
Fix Committed |
|
| 2015-05-21 10:24:21 |
Andy Whitcroft |
linux-lts-trusty (Ubuntu Precise): status |
In Progress |
Fix Committed |
|
| 2015-05-21 10:24:25 |
Andy Whitcroft |
linux (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2015-06-08 14:02:31 |
Chris J Arges |
linux (Ubuntu): assignee |
Chris J Arges (arges) |
|
|
| 2016-04-24 10:42:42 |
Rolf Leggewie |
linux (Ubuntu Utopic): status |
Fix Committed |
Won't Fix |
|
| 2016-09-21 11:16:46 |
Chris J Arges |
linux (Ubuntu Trusty): assignee |
Chris J Arges (arges) |
|
|
| 2016-09-21 11:16:48 |
Chris J Arges |
linux (Ubuntu Utopic): assignee |
Chris J Arges (arges) |
|
|
| 2016-09-21 11:16:50 |
Chris J Arges |
linux-lts-trusty (Ubuntu Precise): assignee |
Chris J Arges (arges) |
|
|
| 2021-10-14 01:13:33 |
Steve Langasek |
linux-lts-trusty (Ubuntu Precise): status |
Fix Committed |
Won't Fix |
|
| 2021-10-14 04:26:45 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Terry Rudd |
