linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ajay Kaher <akaher@vmware.com>
To: <gregkh@linuxfoundation.org>
Cc: <torvalds@linux-foundation.org>, <punit.agrawal@arm.com>,
	<akpm@linux-foundation.org>, <kirill.shutemov@linux.intel.com>,
	<willy@infradead.org>, <will.deacon@arm.com>,
	<mszeredi@redhat.com>, <stable@vger.kernel.org>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	<srivatsab@vmware.com>, <srivatsa@csail.mit.edu>,
	<amakhalov@vmware.com>, <srinidhir@vmware.com>,
	<bvikas@vmware.com>, <anishs@vmware.com>,
	<vsirnapalli@vmware.com>, <srostedt@vmware.com>,
	<akaher@vmware.com>
Subject: [PATCH v2 0/8] Backported fixes for 4.4 stable tree
Date: Wed, 9 Oct 2019 06:14:15 +0530	[thread overview]
Message-ID: <1570581863-12090-1-git-send-email-akaher@vmware.com> (raw)

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



             reply	other threads:[~2019-10-08 16:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09  0:44 Ajay Kaher [this message]
2019-10-09  0:44 ` [PATCH v2 1/8] mm: make page ref count overflow check tighter and more explicit Ajay Kaher
2019-10-09  0:44 ` [PATCH v2 2/8] mm: add 'try_get_page()' helper function Ajay Kaher
2019-10-09  0:44 ` [PATCH v2 3/8] mm: handle PTE-mapped tail pages in gerneric fast gup implementaiton Ajay Kaher
2019-10-09  0:44 ` [PATCH v2 4/8] mm, gup: remove broken VM_BUG_ON_PAGE compound check for hugepages Ajay Kaher
2019-10-09  0:44 ` [PATCH v2 5/8] mm, gup: ensure real head page is ref-counted when using hugepages Ajay Kaher
2019-10-09  0:44 ` [PATCH v2 6/8] mm: prevent get_user_pages() from overflowing page refcount Ajay Kaher
2019-10-09 13:13   ` Vlastimil Babka
2019-10-17 16:28     ` Ajay Kaher
2019-10-25  6:18       ` Ajay Kaher
2019-11-06  8:55         ` Vlastimil Babka
2019-11-11  5:00           ` Ajay Kaher
2019-11-21 20:38             ` gregkh
2019-11-29  9:08               ` Vlastimil Babka
2019-10-09  0:44 ` [PATCH v2 7/8] pipe: add pipe_buf_get() helper Ajay Kaher
2019-10-09  0:44 ` [PATCH v2 8/8] fs: prevent page refcount overflow in pipe_buf_get Ajay Kaher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1570581863-12090-1-git-send-email-akaher@vmware.com \
    --to=akaher@vmware.com \
    --cc=akpm@linux-foundation.org \
    --cc=amakhalov@vmware.com \
    --cc=anishs@vmware.com \
    --cc=bvikas@vmware.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mszeredi@redhat.com \
    --cc=punit.agrawal@arm.com \
    --cc=srinidhir@vmware.com \
    --cc=srivatsa@csail.mit.edu \
    --cc=srivatsab@vmware.com \
    --cc=srostedt@vmware.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vsirnapalli@vmware.com \
    --cc=will.deacon@arm.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).