Message-ID: <1570581863-12090-1-git-send-email-akaher@vmware.com>
Date:   Wed, 9 Oct 2019 06:14:15 +0530
From:   Ajay Kaher <akaher@...are.com>
To:     <gregkh@...uxfoundation.org>
CC:     <torvalds@...ux-foundation.org>, <punit.agrawal@....com>,
        <akpm@...ux-foundation.org>, <kirill.shutemov@...ux.intel.com>,
        <willy@...radead.org>, <will.deacon@....com>,
        <mszeredi@...hat.com>, <stable@...r.kernel.org>,
        <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        <srivatsab@...are.com>, <srivatsa@...il.mit.edu>,
        <amakhalov@...are.com>, <srinidhir@...are.com>,
        <bvikas@...are.com>, <anishs@...are.com>, <vsirnapalli@...are.com>,
        <srostedt@...are.com>, <akaher@...are.com>
Subject: [PATCH v2 0/8] Backported fixes for 4.4 stable tree

These patches include few backported fixes for the 4.4 stable
tree.
I would appreciate if you could kindly consider including them in the
next release.

Ajay

---

[Changes from v1]: No changes, only answering Greg's below queries:

>> Why are these needed?  From what I remember, the last patch here is only
>> needed for machines that are "HUGE" and for those, you shouldn't be
>> using 4.4.y anymore anyway, right?  You just end up saving so much more
>> speed and energy using a newer kernel, why would you want to waste it
>> using an older one?
>>
>> So I need a really good reason why to accept these :)
>
> It's been a week, so I'm dropping this from my queue now.  Please resend
> with this information if you still want these in the tree.

> thanks,
> greg k-h

Indeed, the machine needs to have about 140 GB of RAM to exploit
this vulnerability (CVE-2019-11487). However, Photon OS doesn't
impose any limits on the amount of RAM that it supports, so we would
like to safeguard the kernel against this CVE. Also, while newer
versions of Photon OS are on more recent kernels, Photon OS 1.0 uses
the 4.4 stable series, so it would be great to get these patches
included in an upcoming 4.4 stable release.
    
We would also like to have the following patches that are for machines
that are huge:
    
Patch 1: Introduced page_ref_zero_or_close_to_overflow() which helps to
check for small underflows (or _very_ close to overflowing), and ignore
overflows which have strayed into negative territory.
And this is being used inside get_page() and get_page_foll() to reduce the
possibility of overflowing.  
    
Patch 6: Attacker could do direct IO on a page multiple times to trigger 
an overflowing. This patch makes get_user_pages() refuse to if there is
an overflow.
    
Patch 8: This removes another mechanism for overflowing the page refcount
inside pipe_buf_get().
    
---

[PATCH v2 1/8]:
Backporting of upstream commit f958d7b528b1:
mm: make page ref count overflow check tighter and more explicit

[PATCH v2 2/8]:
Backporting of upstream commit 88b1a17dfc3e:
mm: add 'try_get_page()' helper function

[PATCH v2 3/8]:
Backporting of upstream commit 7aef4172c795:
mm: handle PTE-mapped tail pages in gerneric fast gup implementaiton

[PATCH v2 4/8]:
Backporting of upstream commit a3e328556d41:
mm, gup: remove broken VM_BUG_ON_PAGE compound check for hugepages

[PATCH v2 5/8]:
Backporting of upstream commit d63206ee32b6:
mm, gup: ensure real head page is ref-counted when using hugepages

[PATCH v2 6/8]:
Backporting of upstream commit 8fde12ca79af:
mm: prevent get_user_pages() from overflowing page refcount

[PATCH v2 7/8]:
Backporting of upstream commit 7bf2d1df8082:
pipe: add pipe_buf_get() helper

[PATCH v2 8/8]:
Backporting of upstream commit 15fab63e1e57:
fs: prevent page refcount overflow in pipe_buf_get

Powered by blists - more mailing lists