https://github.com/torvalds/linux
Revision 0f751e641a71157aa584c2a2e22fda52b52b8a56 authored by Tyler Hicks on 23 November 2011, 17:31:24 UTC, committed by Tyler Hicks on 23 November 2011, 21:43:53 UTC
From mhalcrow's original commit message:

    Characters with ASCII values greater than the size of
    filename_rev_map[] are valid filename characters.
    ecryptfs_decode_from_filename() will access kernel memory beyond
    that array, and ecryptfs_parse_tag_70_packet() will then decrypt
    those characters. The attacker, using the FNEK of the crafted file,
    can then re-encrypt the characters to reveal the kernel memory past
    the end of the filename_rev_map[] array. I expect low security
    impact since this array is statically allocated in the text area,
    and the amount of memory past the array that is accessible is
    limited by the largest possible ASCII filename character.

This patch solves the issue reported by mhalcrow but with an
implementation suggested by Linus to simply extend the length of
filename_rev_map[] to 256. Characters greater than 0x7A are mapped to
0x00, which is how invalid characters less than 0x7A were previously
being handled.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Michael Halcrow <mhalcrow@google.com>
Cc: stable@kernel.org
1 parent 32001d6
History
Tip revision: 0f751e641a71157aa584c2a2e22fda52b52b8a56 authored by Tyler Hicks on 23 November 2011, 17:31:24 UTC
eCryptfs: Extend array bounds for all filename chars
Tip revision: 0f751e6
File Mode Size
Documentation
arch
block
crypto
drivers
firmware
fs
include
init
ipc
kernel
lib
mm
net
samples
scripts
security
sound
tools
usr
virt
.gitignore -rw-r--r-- 1014 bytes
.mailmap -rw-r--r-- 4.2 KB
COPYING -rw-r--r-- 18.3 KB
CREDITS -rw-r--r-- 92.6 KB
Kbuild -rw-r--r-- 2.5 KB
Kconfig -rw-r--r-- 252 bytes
MAINTAINERS -rw-r--r-- 201.5 KB
Makefile -rw-r--r-- 52.2 KB
README -rw-r--r-- 17.0 KB
REPORTING-BUGS -rw-r--r-- 3.3 KB

README

back to top