ACK: [PATCH 0/1][SRU][Oneiric] eCryptfs: Infinite loop due to overflow in ecryptfs_write()

Tim Gardner rtg.canonical at gmail.com
Mon Mar 5 18:25:06 UTC 2012


On 03/05/2012 10:18 AM, Colin King wrote:
> From: Colin Ian King<colin.king at 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 at canonical.com




More information about the kernel-team mailing list