[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Nov 2022 19:15:05 -0800
From: Kees Cook <keescook@...omium.org>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Alexey Romanov <avromanov@...rdevices.ru>,
linux-kernel@...r.kernel.org, Nick Terrell <terrelln@...com>,
Minchan Kim <minchan@...nel.org>,
Suleiman Souhlal <suleiman@...gle.com>,
Nitin Gupta <ngupta@...are.org>, Jens Axboe <axboe@...nel.dk>,
Nhat Pham <nphamcs@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-block@...r.kernel.org,
"Gustavo A. R. Silva" <gustavo@...eddedor.com>,
linux-next@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: Coverity: zram_recompress(): OVERRUN
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
Powered by blists - more mailing lists