linux-hardening - Re: Coverity: zblock_alloc(): Memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Nov 2022 08:43:19 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Ananda Badmaev <a.badmaev@...cknet.pro>
Cc:     Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
        Minchan Kim <minchan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        linux-mm@...ck.org, linux-doc@...r.kernel.org,
        Vitaly Wool <vitaly.wool@...sulko.com>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        linux-next@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: Coverity: zblock_alloc(): Memory - illegal accesses

On Fri, Nov 18, 2022 at 04:05:36PM +0300, Ananda Badmaev wrote:
> 18.11.2022 01:20, coverity-bot пишет:
> > Coverity reported the following:
> > 
> > *** CID 1527352:  Memory - illegal accesses  (OVERRUN)
> > mm/zblock.c:320 in zblock_alloc()
> > 314     	}
> > 315     	list = &(pool->block_lists[block_type]);
> > 316
> > 317     check:
> > 318     	spin_lock(&list->lock);
> > 319     	/* check if there are free slots in cache */
> > vvv     CID 1527352:  Memory - illegal accesses  (OVERRUN)
> > vvv     Overrunning array of 10208 bytes at byte offset 10208 by dereferencing pointer "list".
> > 320     	block = cache_find_block(list);
> > 321     	if (block)
> > 322     		goto found;
> > 323     	spin_unlock(&list->lock);
> > 324
> > 325     	/* not found block with free slots try to allocate new empty block */
> > 
> > If this is a false positive, please let us know so we can mark it as
> > such, or teach the Coverity rules to be smarter. If not, please make
> > sure fixes get into linux-next. :) For patches fixing this, please
> > include these lines (but double-check the "Fixes" first):
> > 
> > Reported-by: coverity-bot <keescook+coverity-bot@...omium.org>
> > Addresses-Coverity-ID: 1527352 ("Memory - illegal accesses")
> > Fixes: 9097e28c25c8 ("mm: add zblock - new allocator for use via zpool API")
> > 
> > It looks like block_type is not checked to be < ARRAY_SIZE(block_desc)
> > after exiting the earlier loop, so the access through "list" may be past
> > the end of pool->block_lists.
> > 
> 
> There is no need for this check because it is guaranteed that this code will
> be executed only if size <= PAGE_SIZE. Since slot_size for the last list
> even exceeds PAGE_SIZE, block_type will be always valid.

Ah-ha, understood. Well, if you do want to catch it if there is ever a
typo in the block_desc values (which are not obviously >4096 without
sitting down and calculating them), perhaps add:

        if (WARN_ON(block_type >= ARRAY_SIZE(block_desc))
                return -ENOSPC;


-- 
Kees Cook