linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Eric Sandeen <sandeen@redhat.com>,
	fsdevel <linux-fsdevel@vger.kernel.org>
Cc: David Howells <dhowells@redhat.com>
Subject: Re: [PATCH] fscache: Fix cookie key uninit mem / out of bound read
Date: Tue, 25 Sep 2018 14:25:10 -0500	[thread overview]
Message-ID: <191ce62b-a64d-850b-dc79-ccbe00110343@sandeen.net> (raw)
In-Reply-To: <630f5ad3-1751-1e75-6aa7-13e8b6f30aa4@redhat.com>

On 9/6/18 10:31 AM, Eric Sandeen wrote:
> fscache_set_key() seems to have 2 issues related to the memory
> read for hashing in fscache_set_key.
> 
> The first reported was a KASAN error, 
> 
>  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 
> 
> 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.
> 
> When looking over this, it also appears that the inline key is
> insufficiently initialized, zeroing only 3 of the 4 slots.  Hence
> an index_key_len between 13 and 15 bytes will end up hashing uninitialized
> memory because the memcpy only partially fills the last buf[] element.
> 
> Fix this by calculating how many u32 buffers we'll need by using
> DIV_ROUND_UP, and memset them all to zero before copying in the index_key,
> then using that same count as the hashing index limit.
> 
> Reported-by: syzbot+a95b989b2dde8e806af8@syzkaller.appspotmail.com
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---

Seems like a real bug to me.  Any thoughts?

-Eric

> nb: compile-tested only, sorry.
> 
> diff --git a/fs/fscache/cookie.c b/fs/fscache/cookie.c
> index 83bfe04..bc74ae3 100644
> --- a/fs/fscache/cookie.c
> +++ b/fs/fscache/cookie.c
> @@ -83,7 +83,7 @@ void fscache_cookie_init_once(void *_cookie)
>  }
>  
>  /*
> - * Set the index key in a cookie.  The cookie struct has space for a 12-byte
> + * Set the index key in a cookie.  The cookie struct has space for a 16-byte
>   * key plus length and hash, but if that's not big enough, it's instead a
>   * pointer to a buffer containing 3 bytes of hash, 1 byte of length and then
>   * the key data.
> @@ -93,22 +93,22 @@ static int fscache_set_key(struct fscache_cookie *cookie,
>  {
>  	unsigned long long h;
>  	u32 *buf;
> +	int bufs;
>  	int i;
>  
>  	cookie->key_len = index_key_len;
> +	bufs = DIV_ROUND_UP(index_key_len, sizeof(*buf));
>  
>  	if (index_key_len > sizeof(cookie->inline_key)) {
> -		buf = kzalloc(index_key_len, GFP_KERNEL);
> +		buf = kmalloc_array(bufs, sizeof(*buf), GFP_KERNEL);
>  		if (!buf)
>  			return -ENOMEM;
>  		cookie->key = buf;
>  	} else {
>  		buf = (u32 *)cookie->inline_key;
> -		buf[0] = 0;
> -		buf[1] = 0;
> -		buf[2] = 0;
>  	}
>  
> +	memset(buf, 0, bufs * sizeof(*buf));
>  	memcpy(buf, index_key, index_key_len);
>  
>  	/* Calculate a hash and combine this with the length in the first word
> @@ -116,7 +116,8 @@ static int fscache_set_key(struct fscache_cookie *cookie,
>  	 */
>  	h = (unsigned long)cookie->parent;
>  	h += index_key_len + cookie->type;
> -	for (i = 0; i < (index_key_len + sizeof(u32) - 1) / sizeof(u32); i++)
> +
> +	for (i = 0; i < bufs; i++)
>  		h += buf[i];
>  
>  	cookie->key_hash = h ^ (h >> 32);
> 

      reply	other threads:[~2018-09-26  1:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 15:31 [PATCH] fscache: Fix cookie key uninit mem / out of bound read Eric Sandeen
2018-09-25 19:25 ` Eric Sandeen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=191ce62b-a64d-850b-dc79-ccbe00110343@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).