Messages in this thread |  | | Subject | Re: [PATCH] xen: hypercall: fix out-of-bounds memcpy | From | Boris Ostrovsky <> | Date | Sun, 4 Feb 2018 13:55:25 -0500 |
| |
On 02/04/2018 10:35 AM, Arnd Bergmann wrote: > On Sat, Feb 3, 2018 at 6:08 PM, Boris Ostrovsky > <boris.ostrovsky@oracle.com> wrote: >> >> On 02/03/2018 10:12 AM, Arnd Bergmann wrote: >>> On Sat, Feb 3, 2018 at 12:33 AM, Boris Ostrovsky >>> <boris.ostrovsky@oracle.com> wrote: >>>> On 02/02/2018 10:32 AM, Arnd Bergmann wrote: >>>>> The legacy hypercall handlers were originally added with >>>>> a comment explaining that "copying the argument structures in >>>>> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local >>>>> variable is sufficiently safe" and only made sure to not write >>>>> past the end of the argument structure, the checks in linux/string.h >>>>> disagree with that, when link-time optimizations are used: >>>>> >>>>> In function 'memcpy', >>>>> inlined from 'pirq_query_unmask' at drivers/xen/fallback.c:53:2, >>>>> inlined from '__startup_pirq' at >>>>> drivers/xen/events/events_base.c:529:2, >>>>> inlined from 'restore_pirqs' at >>>>> drivers/xen/events/events_base.c:1439:3, >>>>> inlined from 'xen_irq_resume' at >>>>> drivers/xen/events/events_base.c:1581:2: >>>>> include/linux/string.h:350:3: error: call to '__read_overflow2' declared >>>>> with attribute error: detected read beyond size of object passed as 2nd >>>>> parameter >>>>> __read_overflow2(); >>>>> ^ >>>>> make[3]: *** [ccLujFNx.ltrans15.ltrans.o] Error 1 >>>>> make[3]: Target 'all' not remade because of errors. >>>>> lto-wrapper: fatal error: make returned 2 exit status >>>>> compilation terminated. >>>>> ld: error: lto-wrapper failed >>>>> >>>>> This changes the functions so that each argument is accessed with >>>>> exactly the correct length based on the command code. >>>>> >>>>> Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for >>>>> very old hypervisors") >>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >>>>> --- >>>>> drivers/xen/fallback.c | 94 >>>>> ++++++++++++++++++++++++++++---------------------- >>>>> 1 file changed, 53 insertions(+), 41 deletions(-) >>>>> >>>>> default: >>>>> - WARN_ON(rc != -ENOSYS); >>>>> - break; >>>>> + return -ENOSYS; >>>>> } >>>>> >>>>> + memcpy(&op.u, arg, len); >>>>> + rc = _hypercall1(int, event_channel_op_compat, &op); >>>>> + memcpy(arg, &op.u, len); >>>> >>>> >>>> We don't copy back for all commands, only those that are COPY_BACK. >>> >>> Not sure what you mean. Is it harmful to copy back the data for the others >>> in any way? Otherwise I wouldn't micro-optimize this. >> >> >> I should have checked the original commit for fallback.c --- the code that >> it replaced was doing copybacks for all hypercalls and selective copybacks >> is an optimization introduced in that commit. > It was not an optimization but a correctness fix to avoid overflowing > the caller stack on the copy-back operation. What I tried to explain > in my commit message is that the same fix is also needed on > the copy-out before it. It's only a read access beyond the end > of a local variable, but not both the static checks and kasan-stack > get alarmed about it. >
Yes, I understand that. I was referring to:
Move the fallback code into out-of-line functions, and handle all of the operations known by this old a hypervisor individually: *Some don't require copying back anything at all*, and for the rest use the individual argument structures' sizes rather than the container's
in the original commit. I.e. prior to that commit we *were* copying back for all commands (although possibly with potentially incorrect size). So not copying back for some commands was an optimization.
In any case,
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
|  |