linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Terrell <terrelln@meta.com>
To: Jann Horn <jannh@google.com>
Cc: coverity-bot <keescook@chromium.org>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-hardening@vger.kernel.org"
	<linux-hardening@vger.kernel.org>
Subject: Re: Coverity: HUF_buildCTableFromTree(): Memory - corruptions
Date: Thu, 27 Oct 2022 18:30:34 +0000	[thread overview]
Message-ID: <A8DD8E13-36E8-41C4-B1E9-3367F96A0FFE@fb.com> (raw)
In-Reply-To: <CAG48ez0LRubkXO8aX3VwcF5isZ9z4fKTg48z4Ptr=4d778NcZw@mail.gmail.com>



> On Oct 27, 2022, at 6:43 AM, Jann Horn <jannh@google.com> wrote:
> 
> !-------------------------------------------------------------------|
>  This Message Is From an External Sender
> 
> |-------------------------------------------------------------------!
> 
> On Thu, Oct 27, 2022 at 2:06 AM coverity-bot <keescook@chromium.org> wrote:
>> 
>> Hello!
>> 
>> This is an experimental semi-automated report about issues detected by
>> Coverity from a scan of next-20221026 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:
>> 
>>  Mon Oct 24 12:12:32 2022 -0700
>>    2aa14b1ab2c4 ("zstd: import usptream v1.5.2")
>> 
>> Coverity reported the following:
>> 
>> *** CID 1525550:  Memory - corruptions  (OVERRUN)
>> /lib/zstd/compress/huf_compress.c: 673 in HUF_buildCTableFromTree()
>> 667                 min += nbPerRank[n];
>> 668                 min >>= 1;
>> 669         }   }
>> 670         for (n=0; n<alphabetSize; n++)
>> 671             HUF_setNbBits(ct + huffNode[n].byte, huffNode[n].nbBits);   /* push nbBits per symbol, symbol order */
>> 672         for (n=0; n<alphabetSize; n++)
>> vvv     CID 1525550:  Memory - corruptions  (OVERRUN)
>> vvv     Overrunning array "valPerRank" of 13 2-byte elements at element index 255 (byte offset 511) using index "HUF_getNbBits(ct[n])" (which evaluates to 255).
>> 673             HUF_setValue(ct + n, valPerRank[HUF_getNbBits(ct[n])]++);   /* assign value within rank, symbol order */
>> 674         CTable[0] = maxNbBits;
>> 675     }
>> 676
>> 677     size_t HUF_buildCTable_wksp (HUF_CElt* CTable, const unsigned* count, U32 maxSymbolValue, U32 maxNbBits, void* workSpace, size_t wkspSize)
>> 678     {
> 
> I haven't looked at the other warnings, but from a glance this code
> looks fine to me. Coverity is claiming that some symbols can have 255
> bits, but we just went through HUF_setMaxHeight(), which enforced that
> no symbols have more bits than HUF_TABLELOG_MAX.
> 
> Heuristic checks like this are likely to generate lots of false
> positives in compression code, I think.

Yeah, the warnings in huf_compress.c are definitely false positives.

I'm checking on the others.


  reply	other threads:[~2022-10-27 18:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27  0:05 Coverity: HUF_buildCTableFromTree(): Memory - corruptions coverity-bot
2022-10-27 13:43 ` Jann Horn
2022-10-27 18:30   ` Nick Terrell [this message]
2022-10-27 23:07 ` Nick Terrell
2022-10-28 15:55   ` Kees Cook

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=A8DD8E13-36E8-41C4-B1E9-3367F96A0FFE@fb.com \
    --to=terrelln@meta.com \
    --cc=gustavo@embeddedor.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    /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).