linux-kernel - Re: [PATCH] [iov_iter] use memmove() when copying to/from user page

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]

Date:   Thu, 25 May 2017 19:22:01 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Pavel Machek <pavel@....cz>
Cc:     mtk.manpages@...il.com, Dmitry Vyukov <dvyukov@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        Kostya Serebryany <kcc@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [iov_iter] use memmove() when copying to/from user page

On Thu, May 25, 2017 at 07:04:57PM +0200, Pavel Machek wrote:

> Date: Tue, 16 May 2017 14:27:34 +0200
> From: Alexander Potapenko <glider@...gle.com>
> Subject: [PATCH] [iov_iter] use memmove() when copying to/from user
> page
> 
> BUG: memcpy-param-overlap in generic_perform_write+0x551/0xa20
> __msan_memcpy(ffff88013c6e3001, ffff88013c6e3000, 105)
> CPU: 0 PID: 1040 Comm: probe Not tainted 4.11.0-rc5+ #2562
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
> 01/01/2011
> 
> At the very least, we do not want userland to trigger kernel
> BUG()s... so this needs fixes beyond documentation.

Sure.  Which is to say, the instrumentation that throws such
BUG() is broken and needs to be fixed.

This is bullshit; the _only_ value memmove() would have here is
"doesn't yield false positives from fuck knows what out-of-tree
patches".

It does not make overlapping sendfile() work reliably (while
creating an impression that it just might, as we'd seen in
this thread).  It does not do anything to kernel-vs-userland
aliasing either - copy_from_user() is definitely memcpy()-like,
not memmove()-like.  Not that memmove() worked in situations
when source and destination point to the same memory object
seen at two virtial addresses...