linux-kernel - Re: [PATCH 0/2] page_count can't be used to decide when wp_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:   Sat, 9 Jan 2021 11:03:23 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Andrea Arcangeli <aarcange@...hat.com>
Cc:     Andy Lutomirski <luto@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>,
        Linux-MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>, Yu Zhao <yuzhao@...gle.com>,
        Peter Xu <peterx@...hat.com>,
        Pavel Emelyanov <xemul@...nvz.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Minchan Kim <minchan@...nel.org>,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Matthew Wilcox <willy@...radead.org>,
        Oleg Nesterov <oleg@...hat.com>, Jann Horn <jannh@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        John Hubbard <jhubbard@...dia.com>,
        Leon Romanovsky <leonro@...dia.com>, Jan Kara <jack@...e.cz>,
        Kirill Tkhai <ktkhai@...tuozzo.com>
Subject: Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy

> On Jan 8, 2021, at 3:34 PM, Andrea Arcangeli <aarcange@...hat.com> wrote:
>
> On Fri, Jan 08, 2021 at 10:31:24AM -0800, Andy Lutomirski wrote:
>> Can we just remove vmsplice() support?  We could make it do a normal
>
>> copy, thereby getting rid of a fair amount of nastiness and potential
>> attacks.  Even ignoring issues relating to the length of time that the
>> vmsplice reference is alive, we also have whatever problems could be
>> caused by a malicious or misguided user vmsplice()ing some memory and
>> then modifying it.
>
> Sorry to ask but I'm curious, what also goes wrong if the user
> modifies memory under GUP pin from vmsplice? That's not obvious to
> see.

It breaks the otherwise true rule that the data in pipe buffers is
immutable.  Even just quoting the manpage:

       SPLICE_F_GIFT
              The user pages are a gift to the kernel.   The  application  may
              not  modify  this  memory ever, otherwise the page cache and on-
              disk data may differ.

That's no good.

I can also imagine use cases in which modified vmsplice() pages that
end up in various parts of the network stack could be problematic.
For example, if you can arrange for TCP or, worse, TLS to transmit
data and then retransmit modified data, you might get odd results.  In
the latter case, some security properties of TLS might be broken.

--Andy