]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
fscache: Fix out of bound read in long cookie keys
authorEric Sandeen <sandeen@redhat.com>
Wed, 17 Oct 2018 14:23:59 +0000 (15:23 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 10 Nov 2018 15:49:45 +0000 (07:49 -0800)
commitfc7f79df0f2a5cc781e7e8617b7448e51157311a
tree5082e04e64e617b42c9dafe98826874b72d3364a
parent4bdc50b060ca6eebd0addaa640915e9f008b2539
fscache: Fix out of bound read in long cookie keys

commit fa520c47eaa15b9baa8ad66ac18da4a31679693b upstream.

fscache_set_key() can incur an out-of-bounds read, reported by KASAN:

 BUG: KASAN: slab-out-of-bounds in fscache_alloc_cookie+0x5b3/0x680 [fscache]
 Read of size 4 at addr ffff88084ff056d4 by task mount.nfs/32615

and also reported by syzbot at https://lkml.org/lkml/2018/7/8/236

  BUG: KASAN: slab-out-of-bounds in fscache_set_key fs/fscache/cookie.c:120 [inline]
  BUG: KASAN: slab-out-of-bounds in fscache_alloc_cookie+0x7a9/0x880 fs/fscache/cookie.c:171
  Read of size 4 at addr ffff8801d3cc8bb4 by task syz-executor907/4466

This happens for any index_key_len which is not divisible by 4 and is
larger than the size of the inline key, because the code allocates exactly
index_key_len for the key buffer, but the hashing loop is stepping through
it 4 bytes (u32) at a time in the buf[] array.

Fix this by calculating how many u32 buffers we'll need by using
DIV_ROUND_UP, and then using kcalloc() to allocate a precleared allocation
buffer to hold the index_key, then using that same count as the hashing
index limit.

Fixes: ec0328e46d6e ("fscache: Maintain a catalogue of allocated cookies")
Reported-by: syzbot+a95b989b2dde8e806af8@syzkaller.appspotmail.com
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/fscache/cookie.c