xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: New Defects reported by Coverity Scan for XenProject
Date: Mon, 12 Jun 2023 12:06:47 +0100	[thread overview]
Message-ID: <cfba8e6a-1c76-c678-b0f5-93af91d27606@citrix.com> (raw)
In-Reply-To: <59b7b181-9f31-c3b0-e54f-b5f22b08572a@suse.com>

On 12/06/2023 11:54 am, Jan Beulich wrote:
> On 11.06.2023 12:07, scan-admin@coverity.com wrote:
>> *** CID 1532318:  Memory - corruptions  (OVERLAPPING_COPY)
>> /tools/firmware/xen-dir/xen-root/xen/arch/x86/x86_emulate/x86_emulate.c: 1987 in x86_emulate()
>> 1981             dst.val  = *dst.reg;
>> 1982             goto xchg;
>> 1983     
>> 1984         case 0x98: /* cbw/cwde/cdqe */
>> 1985             switch ( op_bytes )
>> 1986             {
>>>>>     CID 1532318:  Memory - corruptions  (OVERLAPPING_COPY)
>>>>>     Assigning "_regs.al" to "_regs.ax", which have overlapping memory locations and different types.
>> 1987             case 2: _regs.ax = (int8_t)_regs.al; break; /* cbw */
> I was under the impression that reading and then writing different parts
> of the same union was permitted, even without -fno-strict-aliasing. Am I
> missing anything here that Coverity knows better?

It's permitted (hence why it compiles), and it's almost always a bug
(hence why Coverity complains).

In this case it's intentional to sign extend %al to %ax.

>
>> *** CID 1532317:  Insecure data handling  (TAINTED_SCALAR)
>> /tools/libs/guest/xg_dom_bzimageloader.c: 574 in xc_try_zstd_decode()
>> 568         if ( xc_dom_kernel_check_size(dom, outsize) )
>> 569         {
>> 570             DOMPRINTF("ZSTD: output too large");
>> 571             return -1;
>> 572         }
>> 573     
>>>>>     CID 1532317:  Insecure data handling  (TAINTED_SCALAR)
>>>>>     Passing tainted expression "outsize" to "malloc", which uses it as an allocation size.
>> 574         outbuf = malloc(outsize);
>> 575         if ( !outbuf )
>> 576         {
>> 577             DOMPRINTF("ZSTD: failed to alloc memory");
>> 578             return -1;
>> 579         }
> I'm afraid I simply don't know what "tainted expression" here means.
> xc_dom_kernel_check_size() certainly applies an upper bound ...

"tainted" is Coverity-speak for "externally-provided value not sanitised
yet".

I suspect that Coverity has failed to equate xc_dom_kernel_check_size()
to being a bounds check on outsize.

>
>> *** CID 1532309:  Control flow issues  (DEADCODE)
>> /tools/ocaml/libs/xc/xenctrl_stubs.c: 840 in physinfo_arch_caps()
>> 834     
>> 835     	arch_obj = Tag_cons;
>> 836     
>> 837     #endif
>> 838     
>> 839     	if ( tag < 0 )
>>>>>     CID 1532309:  Control flow issues  (DEADCODE)
>>>>>     Execution cannot reach this statement: "caml_failwith("Unhandled ar...".
>> 840     		caml_failwith("Unhandled architecture");
>> 841     
>> 842     	arch_cap_flags = caml_alloc_small(1, tag);
>> 843     	Store_field(arch_cap_flags, 0, arch_obj);
>> 844     
>> 845     	CAMLreturn(arch_cap_flags);
> I think this wants to be left as is, not matter that Coverity complains.

Yeah, this is deliberately too.  It's there to prevent other accidents
like we had last week with the bindings.

~Andrew


  reply	other threads:[~2023-06-12 11:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <64859cf3a1e46_712752abb10eab98834b9@prd-scan-dashboard-0.mail>
2023-06-12 10:54 ` New Defects reported by Coverity Scan for XenProject Jan Beulich
2023-06-12 11:06   ` Andrew Cooper [this message]
     [not found] <664dc165759df_5e9362b92d249399c762@prd-scan-dashboard-0.mail>
2024-05-22 10:05 ` Jan Beulich
2024-05-22 13:49   ` Andrew Cooper
     [not found] <6637576caf98c_10d9e42c57d37559ac60499@prd-scan-dashboard-0.mail>
2024-05-06  7:46 ` Jan Beulich
     [not found] <6547674e54da3_1c3af2c62521719a8359bc@prd-scan-dashboard-0.mail>
2023-11-06  7:36 ` Jan Beulich
     [not found] <600d4d7f99bc3_241662b17c874cf6097f1@prd-scan-dashboard-0.mail>
2021-01-25 10:14 ` Jan Beulich
     [not found] <5700f7b3e7d5c_3fdf4db3186252@ss1435.mail>
2016-04-04 15:07 ` Ian Jackson
     [not found] <56ce8ad13abd2_bd9abd33094410@ss1435.mail>
2016-02-25 10:00 ` Ian Campbell
2016-02-25 10:06   ` George Dunlap
     [not found] <551be9e0474d8_2970d1331454394@scan.coverity.com.mail>
2015-04-02 14:32 ` Ian Campbell
2015-04-02 15:43   ` Charles Arnold
     [not found] <E1Vgaam-0000UH-GS@build-l3.scan.coverity.com>
2013-11-13 13:51 ` Ian Campbell
2013-11-13 14:01   ` David Vrabel

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=cfba8e6a-1c76-c678-b0f5-93af91d27606@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.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).