This bug was filed against a series that is no longer supported and so
is being marked as Won't Fix. If this issue still exists in a supported
series, please file a new bug.
This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.
** Changed in: linux (Ubuntu)
** Changed in: linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/721955
Title:
ftruncate DoS on ecryptfs
To manage notifications about this bug go to:
htt
three may be no activity but the bug is still there
** Changed in: linux (Ubuntu)
Status: Expired => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/721955
Title:
ftruncate DoS on ecryptfs
[Expired for linux (Ubuntu) because there has been no activity for 60
days.]
** Changed in: linux (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/721955
Ti
i can confirm that it is not fixed in upstream and it only affects
32-bit systems where size_t is an unsigned int while loff_t is long
long. on 64-bit archs size_t is unsigned long which means it's 64-bit as
well.
ecryptfs_* functions need to be converted to use loff_t everywhere.
** Tags removed
i'd like to add that this not a purely theoretical problem, it can be
triggered by downloading a torrent with individual file > 4G in size
with Transmission.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bu
I looked at the 2.6.37.1 source, and I can still see the bug in the
source. I won't have time to actually test it this week.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/721955
Title:
ftruncate DoS
Hi Kasper,
If you could also please test the latest upstream kernel available that would
be great. It will allow additional upstream developers to examine the issue.
Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the
upstream kernel, please remove the 'needs-upstr
The bug is in fs/ecryptfs/read_write.c in the function ecryptfs_write().
It uses 32 bit variables for total_remaining_bytes and
total_remaining_zeros. This causes the value to be truncated, and
num_bytes will become zero. At that point each iteration of the loop
will increase the filesize by zero b
I noticed that some of my tests had triggered these kernel log messages:
[151299.267207] ecryptfs_read_lower: octets_read = [-4]; expected [4096]
[151299.267214] ecryptfs_read_and_validate_header_region: Error reading header
region; rc = [-22]
[151345.461122] ecryptfs_read_lower: octets_read = [-4
I tried: strace -t dd if=/dev/zero of=foo bs=4k seek=1048570 count=10
Which showed that it is possible to truncate a file to just under the
4GB mark and then write past the 4GB mark.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
htt
This is worse than I first thought. The time grows roughly linear up to
4GB, then apparently enters an infinite loop. Below is the program I
used to time it. On my system it takes 4 minutes to truncate a file to
just under 4GB (something that takes 14 microseconds without ecryptfs).
For 4GB it has
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/721955
Title:
ftruncate DoS on ecryptfs
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
13 matches
Mail list logo
