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
| ||
|
Message-ID: <918e9f4b-d1bc-95b4-3768-f6a28d625d58@nvidia.com> Date: Tue, 10 Dec 2019 16:27:02 -0800 From: John Hubbard <jhubbard@...dia.com> To: Jan Kara <jack@...e.cz> CC: Andrew Morton <akpm@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>, Alex Williamson <alex.williamson@...hat.com>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Björn Töpel <bjorn.topel@...el.com>, Christoph Hellwig <hch@...radead.org>, Dan Williams <dan.j.williams@...el.com>, Daniel Vetter <daniel@...ll.ch>, Dave Chinner <david@...morbit.com>, David Airlie <airlied@...ux.ie>, "David S . Miller" <davem@...emloft.net>, Ira Weiny <ira.weiny@...el.com>, Jason Gunthorpe <jgg@...pe.ca>, Jens Axboe <axboe@...nel.dk>, Jonathan Corbet <corbet@....net>, Jérôme Glisse <jglisse@...hat.com>, Magnus Karlsson <magnus.karlsson@...el.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Michael Ellerman <mpe@...erman.id.au>, Michal Hocko <mhocko@...e.com>, "Mike Kravetz" <mike.kravetz@...cle.com>, Paul Mackerras <paulus@...ba.org>, "Shuah Khan" <shuah@...nel.org>, Vlastimil Babka <vbabka@...e.cz>, <bpf@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>, <kvm@...r.kernel.org>, <linux-block@...r.kernel.org>, <linux-doc@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>, <linux-media@...r.kernel.org>, <linux-rdma@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>, <netdev@...r.kernel.org>, <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v8 24/26] mm/gup: track FOLL_PIN pages On 12/10/19 5:39 AM, Jan Kara wrote: ... >> +void grab_page(struct page *page, unsigned int flags) >> +{ >> + if (flags & FOLL_GET) >> + get_page(page); >> + else if (flags & FOLL_PIN) { >> + get_page(page); >> + WARN_ON_ONCE(flags & FOLL_GET); >> + /* >> + * Use get_page(), above, to do the refcount error >> + * checking. Then just add in the remaining references: >> + */ >> + page_ref_add(page, GUP_PIN_COUNTING_BIAS - 1); > > This is wrong for two reasons: > > 1) You miss compound_head() indirection from get_page() for this > page_ref_add(). whoops, yes that is missing. > > 2) page_ref_add() could overflow the counter without noticing. > > Especially with GUP_PIN_COUNTING_BIAS being non-trivial, it is realistic > that an attacker might try to overflow the page refcount and we have to > protect the kernel against that. So I think that all the places that would > use grab_page() actually need to use try_grab_page() and then gracefully > deal with the failure. > OK, I've replaced grab_page() everywhere with try_grab_page(), with the above issues fixed. The v7 patchset had error handling for grab_page() failures, that had been reviewed, so relevants parts of that have reappeared. I had initially hesitated to do this, but now I've gone ahead and added: #define page_ref_zero_or_close_to_bias_overflow(page) \ ((unsigned int) page_ref_count(page) + \ GUP_PIN_COUNTING_BIAS <= GUP_PIN_COUNTING_BIAS) ...which is used in the new try_grab_page() for protection. >> @@ -278,11 +425,23 @@ static struct page *follow_page_pte(struct vm_area_struct *vma, >> goto retry; >> } >> >> - if (flags & FOLL_GET) { >> + if (flags & (FOLL_PIN | FOLL_GET)) { >> + /* >> + * Allow try_get_page() to take care of error handling, for >> + * both cases: FOLL_GET or FOLL_PIN: >> + */ >> if (unlikely(!try_get_page(page))) { >> page = ERR_PTR(-ENOMEM); >> goto out; >> } >> + >> + if (flags & FOLL_PIN) { >> + WARN_ON_ONCE(flags & FOLL_GET); >> + >> + /* We got a +1 refcount from try_get_page(), above. */ >> + page_ref_add(page, GUP_PIN_COUNTING_BIAS - 1); >> + __update_proc_vmstat(page, NR_FOLL_PIN_REQUESTED, 1); >> + } >> } > > The same problem here as above, plus this place should use the same > try_grab..() helper, shouldn't it? Yes, now that the new try_grab_page() has behavior that matches what this call site needs. Done. > >> @@ -544,8 +703,8 @@ static struct page *follow_page_mask(struct vm_area_struct *vma, >> /* make this handle hugepd */ >> page = follow_huge_addr(mm, address, flags & FOLL_WRITE); >> if (!IS_ERR(page)) { >> - BUG_ON(flags & FOLL_GET); >> - return page; >> + WARN_ON_ONCE(flags & (FOLL_GET | FOLL_PIN)); >> + return NULL; > > I agree with the change to WARN_ON_ONCE but why is correct the change of > the return value? Note that this is actually a "success branch". > Good catch, thanks! I worked through the logic...correctly at first, but then I must have become temporarily dazed by the raw destructive power of the pre-existing BUG_ON() statement, and screwed it up after all. :) thanks, -- John Hubbard NVIDIA
Powered by blists - more mailing lists