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