linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Coverity: zram_recompress(): OVERRUN
@ 2022-11-10 16:47 coverity-bot
  2022-11-11  0:26 ` Sergey Senozhatsky
  2022-11-11  0:37 ` Sergey Senozhatsky
  0 siblings, 2 replies; 7+ messages in thread
From: coverity-bot @ 2022-11-10 16:47 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Alexey Romanov, linux-kernel, Nick Terrell, Minchan Kim,
	Suleiman Souhlal, Nitin Gupta, Jens Axboe, Nhat Pham,
	Andrew Morton, linux-block, Gustavo A. R. Silva, linux-next,
	linux-hardening

Hello!

This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20221110 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan

You're getting this email because you were associated with the identified
lines of code (noted below) that were touched by commits:

  Wed Nov 9 20:33:48 2022 -0800
    03e6c729aa64 ("zram: introduce recompress sysfs knob")

Coverity reported the following:

*** CID 1527270:    (OVERRUN)
drivers/block/zram/zram_drv.c:1727 in zram_recompress()
1721     		zstrm = zcomp_stream_get(zram->comps[prio]);
1722     		src = kmap_atomic(page);
1723     		ret = zcomp_compress(zstrm, src, &comp_len_new);
1724     		kunmap_atomic(src);
1725
1726     		if (ret) {
vvv     CID 1527270:    (OVERRUN)
vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
1727     			zcomp_stream_put(zram->comps[prio]);
1728     			return ret;
1729     		}
1730
1731     		class_index_new = zs_lookup_class_index(zram->mem_pool,
1732     							comp_len_new);
drivers/block/zram/zram_drv.c:1786 in zram_recompress()
1780     	handle_new = zs_malloc(zram->mem_pool, comp_len_new,
1781     			       __GFP_KSWAPD_RECLAIM |
1782     			       __GFP_NOWARN |
1783     			       __GFP_HIGHMEM |
1784     			       __GFP_MOVABLE);
1785     	if (IS_ERR_VALUE(handle_new)) {
vvv     CID 1527270:    (OVERRUN)
vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
1786     		zcomp_stream_put(zram->comps[prio]);
1787     		return PTR_ERR((void *)handle_new);
1788     	}
1789
1790     	dst = zs_map_object(zram->mem_pool, handle_new, ZS_MM_WO);
1791     	memcpy(dst, zstrm->buffer, comp_len_new);
drivers/block/zram/zram_drv.c:1737 in zram_recompress()
1731     		class_index_new = zs_lookup_class_index(zram->mem_pool,
1732     							comp_len_new);
1733
1734     		/* Continue until we make progress */
1735     		if (class_index_new >= class_index_old ||
1736     		    (threshold && comp_len_new >= threshold)) {
vvv     CID 1527270:    (OVERRUN)
vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
1737     			zcomp_stream_put(zram->comps[prio]);
1738     			continue;
1739     		}
1740
1741     		/* Recompression was successful so break out */
1742     		break;
drivers/block/zram/zram_drv.c:1721 in zram_recompress()
1715     		 * priority algorithm (or same algorithm).
1716     		 */
1717     		if (prio <= zram_get_priority(zram, index))
1718     			continue;
1719
1720     		num_recomps++;
vvv     CID 1527270:    (OVERRUN)
vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
1721     		zstrm = zcomp_stream_get(zram->comps[prio]);
1722     		src = kmap_atomic(page);
1723     		ret = zcomp_compress(zstrm, src, &comp_len_new);
1724     		kunmap_atomic(src);
1725
1726     		if (ret) {
drivers/block/zram/zram_drv.c:1710 in zram_recompress()
1704     	class_index_old = zs_lookup_class_index(zram->mem_pool, comp_len_old);
1705     	/*
1706     	 * Iterate the secondary comp algorithms list (in order of priority)
1707     	 * and try to recompress the page.
1708     	 */
1709     	for (; prio < prio_max; prio++) {
vvv     CID 1527270:    (OVERRUN)
vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
1710     		if (!zram->comps[prio])
1711     			continue;
1712
1713     		/*
1714     		 * Skip if the object is already re-compressed with a higher
1715     		 * priority algorithm (or same algorithm).

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@chromium.org>
Addresses-Coverity-ID: 1527270 ("OVERRUN")
Fixes: 03e6c729aa64 ("zram: introduce recompress sysfs knob")

Thanks for your attention!

-- 
Coverity-bot

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Coverity: zram_recompress(): OVERRUN
  2022-11-10 16:47 Coverity: zram_recompress(): OVERRUN coverity-bot
@ 2022-11-11  0:26 ` Sergey Senozhatsky
  2022-11-11  3:15   ` Kees Cook
  2022-11-11  0:37 ` Sergey Senozhatsky
  1 sibling, 1 reply; 7+ messages in thread
From: Sergey Senozhatsky @ 2022-11-11  0:26 UTC (permalink / raw)
  To: coverity-bot
  Cc: Sergey Senozhatsky, Alexey Romanov, linux-kernel, Nick Terrell,
	Minchan Kim, Suleiman Souhlal, Nitin Gupta, Jens Axboe,
	Nhat Pham, Andrew Morton, linux-block, Gustavo A. R. Silva,
	linux-next, linux-hardening

On (22/11/10 08:47), coverity-bot wrote:
> *** CID 1527270:    (OVERRUN)
> drivers/block/zram/zram_drv.c:1727 in zram_recompress()
> 1721     		zstrm = zcomp_stream_get(zram->comps[prio]);
> 1722     		src = kmap_atomic(page);
> 1723     		ret = zcomp_compress(zstrm, src, &comp_len_new);
> 1724     		kunmap_atomic(src);
> 1725
> 1726     		if (ret) {
> vvv     CID 1527270:    (OVERRUN)
> vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).

Hmm... I don't really see how prio can evaluate to 4.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Coverity: zram_recompress(): OVERRUN
  2022-11-10 16:47 Coverity: zram_recompress(): OVERRUN coverity-bot
  2022-11-11  0:26 ` Sergey Senozhatsky
@ 2022-11-11  0:37 ` Sergey Senozhatsky
  2022-11-11  0:42   ` Sergey Senozhatsky
  1 sibling, 1 reply; 7+ messages in thread
From: Sergey Senozhatsky @ 2022-11-11  0:37 UTC (permalink / raw)
  To: coverity-bot
  Cc: Sergey Senozhatsky, Alexey Romanov, linux-kernel, Nick Terrell,
	Minchan Kim, Suleiman Souhlal, Nitin Gupta, Jens Axboe,
	Nhat Pham, Andrew Morton, linux-block, Gustavo A. R. Silva,
	linux-next, linux-hardening

On (22/11/10 08:47), coverity-bot wrote:
[..]
> 1704     	class_index_old = zs_lookup_class_index(zram->mem_pool, comp_len_old);
> 1705     	/*
> 1706     	 * Iterate the secondary comp algorithms list (in order of priority)
> 1707     	 * and try to recompress the page.
> 1708     	 */
> 1709     	for (; prio < prio_max; prio++) {
> vvv     CID 1527270:    (OVERRUN)
> vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
> 1710     		if (!zram->comps[prio])
> 1711     			continue;
> 1712
> 1713     		/*
> 1714     		 * Skip if the object is already re-compressed with a higher
> 1715     		 * priority algorithm (or same algorithm).

prio_max is always limited and max value it can have is 4 (ZRAM_MAX_COMPS).
Depending on use case we can limit prio_max even to lower values.

So we have

	for (; prio < 4; prio++) {
		foo = comps[prio];
	}

I don't see how prio can be 4 inside of this loop.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Coverity: zram_recompress(): OVERRUN
  2022-11-11  0:37 ` Sergey Senozhatsky
@ 2022-11-11  0:42   ` Sergey Senozhatsky
  2022-11-11  3:16     ` Kees Cook
  0 siblings, 1 reply; 7+ messages in thread
From: Sergey Senozhatsky @ 2022-11-11  0:42 UTC (permalink / raw)
  To: coverity-bot
  Cc: Alexey Romanov, linux-kernel, Nick Terrell, Minchan Kim,
	Suleiman Souhlal, Nitin Gupta, Jens Axboe, Nhat Pham,
	Andrew Morton, linux-block, Gustavo A. R. Silva, linux-next,
	linux-hardening, Sergey Senozhatsky

On (22/11/11 09:37), Sergey Senozhatsky wrote:
> On (22/11/10 08:47), coverity-bot wrote:
> [..]
> > 1704     	class_index_old = zs_lookup_class_index(zram->mem_pool, comp_len_old);
> > 1705     	/*
> > 1706     	 * Iterate the secondary comp algorithms list (in order of priority)
> > 1707     	 * and try to recompress the page.
> > 1708     	 */
> > 1709     	for (; prio < prio_max; prio++) {
> > vvv     CID 1527270:    (OVERRUN)
> > vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
> > 1710     		if (!zram->comps[prio])
> > 1711     			continue;
> > 1712
> > 1713     		/*
> > 1714     		 * Skip if the object is already re-compressed with a higher
> > 1715     		 * priority algorithm (or same algorithm).
> 
> prio_max is always limited and max value it can have is 4 (ZRAM_MAX_COMPS).
> Depending on use case we can limit prio_max even to lower values.
> 
> So we have
> 
> 	for (; prio < 4; prio++) {
> 		foo = comps[prio];
> 	}
> 
> I don't see how prio can be 4 inside of this loop.

Kees, if we do something like this will it make coverity happy?

---

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9d33801e8ba8..e67a124f2e88 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1706,6 +1706,7 @@ static int zram_recompress(struct zram *zram, u32 index, struct page *page,
 	 * Iterate the secondary comp algorithms list (in order of priority)
 	 * and try to recompress the page.
 	 */
+	prio_max = min(prio_max, ZRAM_MAX_COMPS);
 	for (; prio < prio_max; prio++) {
 		if (!zram->comps[prio])
 			continue;

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: Coverity: zram_recompress(): OVERRUN
  2022-11-11  0:26 ` Sergey Senozhatsky
@ 2022-11-11  3:15   ` Kees Cook
  2022-11-11 10:39     ` Sergey Senozhatsky
  0 siblings, 1 reply; 7+ messages in thread
From: Kees Cook @ 2022-11-11  3:15 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Alexey Romanov, linux-kernel, Nick Terrell, Minchan Kim,
	Suleiman Souhlal, Nitin Gupta, Jens Axboe, Nhat Pham,
	Andrew Morton, linux-block, Gustavo A. R. Silva, linux-next,
	linux-hardening

On Fri, Nov 11, 2022 at 09:26:31AM +0900, Sergey Senozhatsky wrote:
> On (22/11/10 08:47), coverity-bot wrote:
> > *** CID 1527270:    (OVERRUN)
> > drivers/block/zram/zram_drv.c:1727 in zram_recompress()
> > 1721     		zstrm = zcomp_stream_get(zram->comps[prio]);
> > 1722     		src = kmap_atomic(page);
> > 1723     		ret = zcomp_compress(zstrm, src, &comp_len_new);
> > 1724     		kunmap_atomic(src);
> > 1725
> > 1726     		if (ret) {
> > vvv     CID 1527270:    (OVERRUN)
> > vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
> 
> Hmm... I don't really see how prio can evaluate to 4.

Yeah, I agree. This looks like a false positive. I'm not sure why
Coverity triggered for it. Looking at the extended report, it seems to
not have any idea that prio_max is correctly bounded.

Sorry for the noise!

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Coverity: zram_recompress(): OVERRUN
  2022-11-11  0:42   ` Sergey Senozhatsky
@ 2022-11-11  3:16     ` Kees Cook
  0 siblings, 0 replies; 7+ messages in thread
From: Kees Cook @ 2022-11-11  3:16 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Alexey Romanov, linux-kernel, Nick Terrell, Minchan Kim,
	Suleiman Souhlal, Nitin Gupta, Jens Axboe, Nhat Pham,
	Andrew Morton, linux-block, Gustavo A. R. Silva, linux-next,
	linux-hardening

On Fri, Nov 11, 2022 at 09:42:38AM +0900, Sergey Senozhatsky wrote:
> On (22/11/11 09:37), Sergey Senozhatsky wrote:
> > On (22/11/10 08:47), coverity-bot wrote:
> > [..]
> > > 1704     	class_index_old = zs_lookup_class_index(zram->mem_pool, comp_len_old);
> > > 1705     	/*
> > > 1706     	 * Iterate the secondary comp algorithms list (in order of priority)
> > > 1707     	 * and try to recompress the page.
> > > 1708     	 */
> > > 1709     	for (; prio < prio_max; prio++) {
> > > vvv     CID 1527270:    (OVERRUN)
> > > vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
> > > 1710     		if (!zram->comps[prio])
> > > 1711     			continue;
> > > 1712
> > > 1713     		/*
> > > 1714     		 * Skip if the object is already re-compressed with a higher
> > > 1715     		 * priority algorithm (or same algorithm).
> > 
> > prio_max is always limited and max value it can have is 4 (ZRAM_MAX_COMPS).
> > Depending on use case we can limit prio_max even to lower values.
> > 
> > So we have
> > 
> > 	for (; prio < 4; prio++) {
> > 		foo = comps[prio];
> > 	}
> > 
> > I don't see how prio can be 4 inside of this loop.
> 
> Kees, if we do something like this will it make coverity happy?
> 
> ---
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 9d33801e8ba8..e67a124f2e88 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -1706,6 +1706,7 @@ static int zram_recompress(struct zram *zram, u32 index, struct page *page,
>  	 * Iterate the secondary comp algorithms list (in order of priority)
>  	 * and try to recompress the page.
>  	 */
> +	prio_max = min(prio_max, ZRAM_MAX_COMPS);
>  	for (; prio < prio_max; prio++) {
>  		if (!zram->comps[prio])
>  			continue;

It would, but given this is a clear false positive, don't feel the need
to add this just for Coverity's sake. It is a nice bit of added
robustness, but I leave that decision up to you! :)

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Coverity: zram_recompress(): OVERRUN
  2022-11-11  3:15   ` Kees Cook
@ 2022-11-11 10:39     ` Sergey Senozhatsky
  0 siblings, 0 replies; 7+ messages in thread
From: Sergey Senozhatsky @ 2022-11-11 10:39 UTC (permalink / raw)
  To: Kees Cook
  Cc: Sergey Senozhatsky, Alexey Romanov, linux-kernel, Nick Terrell,
	Minchan Kim, Suleiman Souhlal, Nitin Gupta, Jens Axboe,
	Nhat Pham, Andrew Morton, linux-block, Gustavo A. R. Silva,
	linux-next, linux-hardening

On (22/11/10 19:15), Kees Cook wrote:
> On Fri, Nov 11, 2022 at 09:26:31AM +0900, Sergey Senozhatsky wrote:
> > On (22/11/10 08:47), coverity-bot wrote:
> > > *** CID 1527270:    (OVERRUN)
> > > drivers/block/zram/zram_drv.c:1727 in zram_recompress()
> > > 1721     		zstrm = zcomp_stream_get(zram->comps[prio]);
> > > 1722     		src = kmap_atomic(page);
> > > 1723     		ret = zcomp_compress(zstrm, src, &comp_len_new);
> > > 1724     		kunmap_atomic(src);
> > > 1725
> > > 1726     		if (ret) {
> > > vvv     CID 1527270:    (OVERRUN)
> > > vvv     Overrunning array "zram->comps" of 4 8-byte elements at element index 4 (byte offset 39) using index "prio" (which evaluates to 4).
> > 
> > Hmm... I don't really see how prio can evaluate to 4.
> 
> Yeah, I agree. This looks like a false positive. I'm not sure why
> Coverity triggered for it. Looking at the extended report, it seems to
> not have any idea that prio_max is correctly bounded.
> 
> Sorry for the noise!

No worries!

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-11-11 10:39 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-10 16:47 Coverity: zram_recompress(): OVERRUN coverity-bot
2022-11-11  0:26 ` Sergey Senozhatsky
2022-11-11  3:15   ` Kees Cook
2022-11-11 10:39     ` Sergey Senozhatsky
2022-11-11  0:37 ` Sergey Senozhatsky
2022-11-11  0:42   ` Sergey Senozhatsky
2022-11-11  3:16     ` Kees Cook

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).