Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Ubuntu Kernel Team (http://www.linux-archive.org/ubuntu-kernel-team/)
-   -   ACK: eCryptfs: Infinite loop due to overflow in ecryptfs_write() (http://www.linux-archive.org/ubuntu-kernel-team/641147-ack-ecryptfs-infinite-loop-due-overflow-ecryptfs_write.html)

Tim Gardner 03-05-2012 05:25 PM

ACK: eCryptfs: Infinite loop due to overflow in ecryptfs_write()
 
On 03/05/2012 10:18 AM, Colin King wrote:

From: Colin Ian King<colin.king@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/947143

SRU justification:

Impact:

ecryptfs_write() can enter an infinite loop when truncating a file to a
size larger than 4G. This only happens on architectures where size_t is
represented by 32 bits.

This was caused by a size_t overflow due to it incorrectly being used to
store the result of a calculation which uses potentially large values of
type loff_t.

Fix:

Backported commit 684a3ff7e69acc7c678d1a1394fe9e757993fd34 (needed a tiny
bit of backporting attention because it didn't cleanly apply because of
commit 6d7368f9822016069edf2d1a488d71004d3c39cc)

Testcase:

Truncating a non-existent file to 5GB on a 32 bit system
will cause the truncate to get stuck in an infinite loop
once the lower file is greater than 1GB. Without the fix,
the following will get stuck:

truncate bigfile -s 5G

With, the fix, the file is truncated to 5GB as expected.

Colin Ian King (1):
eCryptfs: Infinite loop due to overflow in ecryptfs_write()

fs/ecryptfs/read_write.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)




--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Brad Figg 03-05-2012 05:28 PM

ACK: eCryptfs: Infinite loop due to overflow in ecryptfs_write()
 
On 03/05/2012 09:18 AM, Colin King wrote:

From: Colin Ian King<colin.king@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/947143

SRU justification:

Impact:

ecryptfs_write() can enter an infinite loop when truncating a file to a
size larger than 4G. This only happens on architectures where size_t is
represented by 32 bits.

This was caused by a size_t overflow due to it incorrectly being used to
store the result of a calculation which uses potentially large values of
type loff_t.

Fix:

Backported commit 684a3ff7e69acc7c678d1a1394fe9e757993fd34 (needed a tiny
bit of backporting attention because it didn't cleanly apply because of
commit 6d7368f9822016069edf2d1a488d71004d3c39cc)

Testcase:

Truncating a non-existent file to 5GB on a 32 bit system
will cause the truncate to get stuck in an infinite loop
once the lower file is greater than 1GB. Without the fix,
the following will get stuck:

truncate bigfile -s 5G

With, the fix, the file is truncated to 5GB as expected.

Colin Ian King (1):
eCryptfs: Infinite loop due to overflow in ecryptfs_write()

fs/ecryptfs/read_write.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)




--
Brad Figg brad.figg@canonical.com http://www.canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team


All times are GMT. The time now is 11:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.