ACK: [Natty][SRU][PATCH 0/1] eCryptfs: Sanitize write counts of /dev/ecryptfs

Stefan Bader stefan.bader at canonical.com
Mon Mar 5 13:46:16 UTC 2012


On 05.03.2012 13:21, Colin King wrote:
> From: Colin Ian King <colin.king at canonical.com>
> 
> BugLink: http://bugs.launchpad.net/bugs/947075
> 
> SRU justification:
> 
> Impact:
> 
> A malicious count value specified when writing to /dev/ecryptfs may
> result in a very large kernel memory allocation.
> 
> Fix:
> 
> Upstream commit db10e556518eb9d21ee92ff944530d84349684f4
> 
> Test case:
> 
> By crafting a ECRYPTFS_MSG_RESPONSE packet and passing a large
> write size we can cause a large kernel memory allocation. With
> the fix EINVAL is returned. See the example code below:
> 
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
> 
> int main(void)
> {
>         unsigned char buf[] = { 103, 0, 0, 0, 0, 220 };
>         ssize_t written;
>         int miscdev;
> 
>         miscdev = open("/dev/ecryptfs", O_WRONLY);
>         if (miscdev < 0)
>                 return 1;
> 
>         written = write(miscdev, buf, 1073741824);
> 
>         close(miscdev);
> 
>         /* The write should fail */
>         return written < 0 ? 0 : 2;
> }
> 
> 
> Note: This patch has already been picked up in Lucid as part of
> the stable updates process, but got overlooked for Natty.
> 
> Tyler Hicks (1):
>   eCryptfs: Extend array bounds for all filename chars
> 
>  fs/ecryptfs/crypto.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 

Given it is upstream and even in Lucid




More information about the kernel-team mailing list