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

Re: [Xen-devel] Uninitialised issue in hvmemul_do_io()

  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Thu, 22 May 2014 10:36:08 +0000
  • Accept-language: en-GB, en-US
  • Cc: Xen-devel List <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 22 May 2014 10:36:17 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHPdah06bzRLZq/Pk2PqNHDsGQ1p5tMZgUw
  • Thread-topic: Uninitialised issue in hvmemul_do_io()

> -----Original Message-----
> From: Andrew Cooper
> Sent: 22 May 2014 11:28
> To: Paul Durrant
> Cc: Xen-devel List
> Subject: Uninitialised issue in hvmemul_do_io()
> Hello,
> The latest Coverity run identified an issue in hvmemul_do_io()
> ioreq_t p; is declared without initialiser.
> By following the false branches, it is possible to get to line 230 of
> hvm/emulate.c in the X86EMUL_UNHANDLEABLE case and call
> hvm_send_assist_req() with a still uninitialised p.
> This is Coverity-ID 1215178

All relevant fields of ioreq_t are initialized between lines 182 and 189 but 
hvm_send_assist_req() does a struct copy so the unitialized value of vp_eport 
is seen as a problem, which it's not because it gets overwritten in the 
destination by the correct value afterwards.

I will submit patch to just init all fields to 0 to get rid of the noise though.


> ~Andrew

Xen-devel mailing list



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