diff options
author | Kees Cook <keescook@chromium.org> | 2018-08-03 12:52:58 -0700 |
---|---|---|
committer | Kees Cook <keescook@chromium.org> | 2018-08-04 07:53:46 -0700 |
commit | 961b33c244e5ba1543ae26270a1ba29f29c2db83 (patch) | |
tree | b2e0bdb72b4e43774aa1264c9bf9f3df1e8cb2d8 /fs/exportfs | |
parent | 7daf201d7fe8334e2d2364d4e8ed3394ec9af819 (diff) | |
download | linux-961b33c244e5ba1543ae26270a1ba29f29c2db83.tar.bz2 |
jfs: Fix usercopy whitelist for inline inode data
Bart Massey reported what turned out to be a usercopy whitelist false
positive in JFS when symlink contents exceeded 128 bytes. The inline
inode data (i_inline) is actually designed to overflow into the "extended
area" following it (i_inline_ea) when needed. So the whitelist needed to
be expanded to include both i_inline and i_inline_ea (the whole size
of which is calculated internally using IDATASIZE, 256, instead of
sizeof(i_inline), 128).
$ cd /mnt/jfs
$ touch $(perl -e 'print "B" x 250')
$ ln -s B* b
$ ls -l >/dev/null
[ 249.436410] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'jfs_ip' (offset 616, size 250)!
Reported-by: Bart Massey <bart.massey@gmail.com>
Fixes: 8d2704d382a9 ("jfs: Define usercopy region in jfs_ip slab cache")
Cc: Dave Kleikamp <shaggy@kernel.org>
Cc: jfs-discussion@lists.sourceforge.net
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Diffstat (limited to 'fs/exportfs')
0 files changed, 0 insertions, 0 deletions