linux-kernel - Re: [PATCH] xen: hypercall: fix out-of-bounds memcpy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a3v=SMcuOtG6xLt0rpAoPx-ox_TaQ=g+stNVWH4HBciHw@mail.gmail.com>
Date:   Sun, 4 Feb 2018 16:35:11 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc:     Juergen Gross <jgross@...e.com>, Nicolas Pitre <nico@...aro.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Jan Beulich <jbeulich@...e.com>,
        xen-devel <xen-devel@...ts.xenproject.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] xen: hypercall: fix out-of-bounds memcpy

On Sat, Feb 3, 2018 at 6:08 PM, Boris Ostrovsky
<boris.ostrovsky@...cle.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@...cle.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@...db.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.

       Arnd