>>> On 16.10.12 at 11:07, "Jan Beulich" <jbeul...@suse.com> wrote:
>>>> On 15.10.12 at 12:27, Ian Campbell <ian.campb...@citrix.com> 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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
