aboutsummaryrefslogtreecommitdiff
path: root/drivers/message
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2008-10-29 14:01:08 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-10-30 11:38:46 -0700
commit87b811c3f96559e466403e22b1fa99d472571625 (patch)
tree319179f5d9a1cffaa3ae32aa41076d0fb10aab10 /drivers/message
parentce05fcc30ea41c85f9d50bee1ce289f7cb7fb223 (diff)
ecryptfs: fix memory corruption when storing crypto info in xattrs
When ecryptfs allocates space to write crypto headers into, before copying it out to file headers or to xattrs, it looks at the value of crypt_stat->num_header_bytes_at_front to determine how much space it needs. This is also used as the file offset to the actual encrypted data, so for xattr-stored crypto info, the value was zero. So, we kzalloc'd 0 bytes, and then ran off to write to that memory. (Which returned as ZERO_SIZE_PTR, so we explode quickly). The right answer is to always allocate a page to write into; the current code won't ever write more than that (this is enforced by the (PAGE_CACHE_SIZE - offset) length in the call to ecryptfs_generate_key_packet_set). To be explicit about this, we now send in a "max" parameter, rather than magically using PAGE_CACHE_SIZE there. Also, since the pointer we pass down the callchain eventually gets the virt_to_page() treatment, we should be using a alloc_page variant, not kzalloc (see also 7fcba054373d5dfc43d26e243a5c9b92069972ee) Signed-off-by: Eric Sandeen <sandeen@redhat.com> Acked-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/message')
0 files changed, 0 insertions, 0 deletions