[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
** Changed in: ecryptfs
Status: Fix Committed = Fix Released
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
This bug was fixed in the package linux - 3.11.0-14.21
---
linux (3.11.0-14.21) saucy; urgency=low
[Brad Figg]
* Release Tracking Bug
- LP: #1250540
[ Anthony Wong ]
* SAUCE: Work around broken ACPI backlight on Dell Inspiron 5537
- LP: #1231305
[ Colin Ian King ]
* SAUCE: eCryptfs: fix 32 bit corruption issue
- LP: #1243636
[ Ming Lei ]
* SAUCE: ext4: fix performance regression in ext4_writepages
- LP: #1242812
[ Upstream Kernel Changes ]
* Revert bridge: only expire the mdb entry when query is received
- LP: #1249081
* ext4: fix performance regression in writeback of random writes
- LP: #1242812
* be2net: pass if_id for v1 and V2 versions of TX_CREATE cmd
- LP: #1234019
* tcp: TSO packets automatic sizing
- LP: #1249081
* tcp: TSQ can use a dynamic limit
- LP: #1249081
* tcp: must unclone packets before mangling them
- LP: #1249081
* tcp: do not forget FIN in tcp_shifted_skb()
- LP: #1249081
* tcp: fix incorrect ca_state in tail loss probe
- LP: #1249081
* net: do not call sock_put() on TIMEWAIT sockets
- LP: #1249081
* batman-adv: set up network coding packet handlers during module init
- LP: #1249081
* l2tp: fix kernel panic when using IPv4-mapped IPv6 addresses
- LP: #1249081
* l2tp: Fix build warning with ipv6 disabled.
- LP: #1249081
* net: mv643xx_eth: update statistics timer from timer context only
- LP: #1249081
* net: mv643xx_eth: fix orphaned statistics timer crash
- LP: #1249081
* net: heap overflow in __audit_sockaddr()
- LP: #1249081
* sit: amend allow to use rtnl ops on fb tunnel
- LP: #1249081
* proc connector: fix info leaks
- LP: #1249081
* ipv4: fix ineffective source address selection
- LP: #1249081
* can: dev: fix nlmsg size calculation in can_get_size()
- LP: #1249081
* net: secure_seq: Fix warning when CONFIG_IPV6 and CONFIG_INET are not
selected
- LP: #1249081
* xen-netback: Don't destroy the netdev until the vif is shut down
- LP: #1249081
* net/mlx4_en: Rename name of mlx4_en_rx_alloc members
- LP: #1249081
* net/mlx4_en: Fix pages never dma unmapped on rx
- LP: #1249081
* net: vlan: fix nlmsg size calculation in vlan_get_size()
- LP: #1249081
* bridge: update mdb expiration timer upon reports.
- LP: #1249081
* vti: get rid of nf mark rule in prerouting
- LP: #1249081
* l2tp: must disable bh before calling l2tp_xmit_skb()
- LP: #1249081
* netem: update backlog after drop
- LP: #1249081
* netem: free skb's in tree on reset
- LP: #1249081
* farsync: fix info leak in ioctl
- LP: #1249081
* unix_diag: fix info leak
- LP: #1249081
* connector: use nlmsg_len() to check message length
- LP: #1249081
* bnx2x: record rx queue for LRO packets
- LP: #1249081
* virtio-net: don't respond to cpu hotplug notifier if we're not ready
- LP: #1249081
* virtio-net: refill only when device is up during setting queues
- LP: #1249081
* bridge: Correctly clamp MAX forward_delay when enabling STP
- LP: #1249081
* net: dst: provide accessor function to dst-xfrm
- LP: #1249081
* sctp: Use software crc32 checksum when xfrm transform will happen.
- LP: #1249081
* sctp: Perform software checksum if packet has to be fragmented.
- LP: #1249081
* wanxl: fix info leak in ioctl
- LP: #1249081
* net: unix: inherit SOCK_PASS{CRED, SEC} flags from socket to fix race
- LP: #1249081
* net: fix cipso packet validation when !NETLABEL
- LP: #1249081
* inet: fix possible memory corruption with UDP_CORK and UFO
- LP: #1249081
* ipv6: always prefer rt6i_gateway if present
- LP: #1249081
* ipv6: fill rt6i_gateway with nexthop address
- LP: #1249081
* netfilter: nf_conntrack: fix rt6i_gateway checks for H.323 helper
- LP: #1249081
* ipv6: probe routes asynchronous in rt6_probe
- LP: #1249081
* davinci_emac.c: Fix IFF_ALLMULTI setup
- LP: #1249081
* ARM: 7851/1: check for number of arguments in
syscall_get/set_arguments()
- LP: #1249081
* ARM: integrator: deactivate timer0 on the Integrator/CP
- LP: #1249081
* ext[34]: fix double put in tmpfile
- LP: #1249081
* gpio/lynxpoint: check if the interrupt is enabled in IRQ handler
- LP: #1249081
* dm snapshot: fix data corruption
- LP: #1249081
- CVE-2013-4299
* i2c: ismt: initialize DMA buffer
- LP: #1249081
* mm: migration: do not lose soft dirty bit if page is in migration state
- LP: #1249081
* mm/zswap: bugfix: memory leak when re-swapon
- LP: #1249081
* mm: fix BUG in __split_huge_page_pmd
- LP: #1249081
* ALSA: us122l: Fix pcm_usb_stream mmapping regression
- LP: #1249081
* ALSA: hda - Fix inverted internal mic not indicated on some machines
- LP: #1227491, #1239392, #1249081
* writeback: fix negative bdi max pause
- LP: #1249081
* w1 - call
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
** Branch linked: lp:ubuntu/saucy-proposed/linux-exynos5
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Committed
Status in “linux” package in Ubuntu:
Fix Committed
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
-proposed works for me. Tested against NUL-File and multiple VirtualBox-
images.
** Tags removed: verification-needed-saucy
** Tags added: verification-done-saucy
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Committed
Status in “linux” package in Ubuntu:
Fix Committed
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
saucy' to 'verification-done-saucy'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
** Tags added: verification-needed-saucy
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Committed
Status in “linux” package in Ubuntu:
Fix Committed
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
** Branch linked: lp:ubuntu/precise-proposed/linux-lts-saucy
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Committed
Status in “linux” package in Ubuntu:
In Progress
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
** Tags removed: kernel-key
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Committed
Status in “linux” package in Ubuntu:
In Progress
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
striscio, problem has been fixed on mainline-kernel 3.12, if you have to, just
update like described in:
http://ubuntuhandbook.org/index.php/2013/11/linux-kernel-3-12-released-install-ubuntu-or-linux-mint/
update to saucy-kernel will be as soon as possible.
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Committed
Status in “linux” package in Ubuntu:
In Progress
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
Any update on this? I would like to use encrypted home, but I need to
use big files for virtualbox
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Committed
Status in “linux” package in Ubuntu:
In Progress
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
** Summary changed:
- ecryptfs currupts files over 4GB size on i686
+ ecryptfs corrupts files over 4GB size on i686
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
In Progress
Status in “linux” package in Ubuntu:
In Progress
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that is currently located in the
eCryptfs next branch:
http://git.kernel.org/cgit/linux/kernel/git/tyhicks/ecryptfs.git/commit/?h=nextid=43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
I've sent a pull request to Linus, but he has not yet had a chance to pull in
the change:
https://lkml.org/lkml/2013/10/24/424
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1243636/+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
[Kernel-packages] [Bug 1243636] Re: ecryptfs corrupts files over 4GB size on i686
** Description changed:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
- identified the problem. It is a simple fix that is currently located in the
- eCryptfs next branch:
+ identified the problem. It is a simple fix that has been merged upstream:
-
http://git.kernel.org/cgit/linux/kernel/git/tyhicks/ecryptfs.git/commit/?h=nextid=43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
-
- I've sent a pull request to Linus, but he has not yet had a chance to pull in
- the change:
-
- https://lkml.org/lkml/2013/10/24/424
+ http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
** Changed in: ecryptfs
Status: In Progress = Fix Committed
--
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/1243636
Title:
ecryptfs corrupts files over 4GB size on i686
Status in eCryptfs:
Fix Committed
Status in “linux” package in Ubuntu:
In Progress
Bug description:
[SRU Justification]
Commit 24d15266bd86b7961f309a962fa3aa177a78c49f introduced a data corruption
regression on 32 bit architectures when writing past the 4 GB.
[Impact]
32 bit users experience corruption of large files.
[Fix]
A cast is needed when shifting the page's index. Colin and I independently
identified the problem. It is a simple fix that has been merged upstream:
http://git.kernel.org/linus/43b7c6c6a4e3916edd186ceb61be0c67d1e0969e
[Test Case]
Inside of an eCryptfs mount on an i686 Ubuntu install, create a file
containing
4 GB + 1 page worth (4096 bytes) of zeros. Then inspect the file for non-zero
bytes.
$ rm zeros
$ dd if=/dev/zero of=zeros bs=4096 count=$((4*1024*1024*1024/4096+4096))
1052672+0 records in
1052672+0 records out
4311744512 bytes (4.3 GB) copied, 226.133 s, 19.1 MB/s
$ hexdump -C zeros
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
10100
The hexdump output should show all zeros. A non patched kernel will show
non-zero bytes.
[Original Bug Report]
on extracting files with extracted size 4 GB files are getting currupted.
interestingly file gets currupted in the very moment the file size gets more
than 4GB.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic i686
ApportVersion: 2.12.5-0ubuntu2
Architecture: i386
Date: Wed Oct 23 12:11:43 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-07-20 (94 days ago)
InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=set
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic
root=UUID=e97431f7-60b7-4fbe-b22f-5ca3304f2d50 ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to saucy on 2013-09-08 (45 days ago)
To manage notifications about this bug go to:
