Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.10.12 at 11:07, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 15.10.12 at 12:27, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>>> My static analyzer complains about potential memory corruption in
>>> HYPERVISOR_physdev_op()
>>> 
>>> arch/x86/include/asm/xen/hypercall.h
>>>    389  static inline int
>>>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>>>    391  {
>>>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>>>    393          if (unlikely(rc == -ENOSYS)) {
>>>    394                  struct physdev_op op;
>>>    395                  op.cmd = cmd;
>>>    396                  memcpy(&op.u, arg, sizeof(op.u));
>>>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>>>    398                  memcpy(arg, &op.u, sizeof(op.u));
>>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Some of the arg buffers are not as large as sizeof(op.u) which is either
>>> 12 or 16 depending on the size of longs in struct physdev_apic.
>> 
>> Nasty!
> 
> Doesn't the same problem also exist for
> HYPERVISOR_event_channel_op() then, at least theoretically
> (EVTCHNOP_reset is apparently the only addition here so far,
> but is being used by the tools only afaics)?

Actually, the problem isn't tied to new additions of sub-hypercalls
(I was wrongly implying this from the example originally provided),
and should be visible e.g. on any use of EVTCHNOP_unmask.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel