[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Defects reported by Coverity Scan for XenProject


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 12 Jun 2023 12:06:47 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1yoXIEgY1VAU/jKDncu1ErBzDxBe2phqSIXTLjBDEXM=; b=PtqCe/XBADszhZpcAMJTZv9RZ7hCjzPB2e3ZMmMeL1hWz28RNbfMjFrCvRMJA8Dbb1oqpvojcZ598YmQCHuyMcXZBFaOK2hrtMtIJd7uqXKZTDgymrMRXpMFdQvdtCuZ+wpBHIJsjFkFlPFPmW5pcChLXX9dML+GUUWLkfsjlk3+UopEW3F17geqdmw8WQGtgFBx285IuBZuKKORr2d36Qdz5Kcq3l3EtDqp3CcVPFIFBnKlgr3LSrGj/Sz9k7BxVzub/UpKrBfuy2p8jEgHxyhGfhJgy5WI05l4Je7z5tb0ifpzPyE6b1clstovdV/z9tyg494I9NG0RYOH4dVCIA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QZDwwtHIACMM61fh29XmWI/a4q5yUAKH/nCUIgwYkwJ/Yy3rfQS8Uhcpv8ETtzyVATucIduPKi4bN98QJrB/wJFWqJietqNXVMcIdUSe3D3ZdPOZXOlMR+rFjBZvB/d7OLXRakwx6ZdYUQwuhgQnak3dvFjBjuCMC9JIWbOa2Dhnia0KBBmOIHd+Tc3YyK1fZlqsLtIvcIfvUE6gjh+U89fZaxDg75Imx+bkZ6c6KGlnQ2X42/yAopfyLxTvGvOM+YVgM8voMEvzx1akJ8YtgvhXFVqsQYtb1s+1IZy1mR0m3Dg3fFXhNHHm6mNlAkLjE0BNS/GcRk6cnOGt9ROqVA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Delivery-date: Mon, 12 Jun 2023 11:07:11 +0000
  • Ironport-data: A9a23:STZ33KNzaPUKdYrvrR28lsFynXyQoLVcMsEvi/4bfWQNrUokhmECn GpOWGqGaf/cYWWge40iYN7g8xsB6pHWzd8yQAto+SlhQUwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CU6jufQAOKnUoYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGjxSs/rrRC9H5qyo42tG5wZmPJingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0s9rDUFr1 8NGFAs2SgDfh9+a4667ceY506zPLOGzVG8ekldJ6GiDSNwAEdXESaiM4sJE1jAtgMwIBezZe 8cSdTtoalLHfgFLPVAUTpk5mY9EhFGmK2Ee9A3T+PdxujeOpOBy+OGF3N79U9qGX8hK2G2fo XrL5T/RCRAGLt2PjzGC9xpAg8eWxHmnBtxISuzQGvhCrnzPwWI9ChwqcEKlm6CQu06FHIxUA hlBksYphe1onKCxdfH/VRClpH+PvjYHRsFdVeY97Wml2qfSpgqUGGUAZjpAc8A98t87QyQw0 V2ElM+vAiZg2IB5UlqY/7aQ6Dm0aS4cKDZYYTdeFFRYpd7+vIs0kxTDCM55F7K4hcH0Hje2x C2WqC85hPMYistjO7iHwG0rSgmE/vDhJjPZLC2ONo55xmuVvLKYWrE=
  • Ironport-hdrordr: A9a23:expmmqCMAfLHOzHlHemK55DYdb4zR+YMi2TDgXoBMyC9Vvbo7v xG+85rsyMc6QxhP03I/OrrBEDuewK+yXcY2+ks1NSZLW3bUQmTXeNfBNDZskXd8kTFn4Y36U 4KSdkaNDSfNzlHpPe/yBWkFc0t2dyWmZrY/ts2DE0AceipUcxdBstCZTpz23cZeDV7
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12/06/2023 11:54 am, Jan Beulich wrote:
> On 11.06.2023 12:07, scan-admin@xxxxxxxxxxxx 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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.