linux-kernel - [PATCH] mm/gup: protect unpin_user

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:   Wed, 16 Sep 2020 23:57:06 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     <dan.carpenter@...cle.com>
CC:     <akpm@...ux-foundation.org>, <alex.bou9@...il.com>,
        <gustavoars@...nel.org>, <ira.weiny@...el.com>,
        <jhubbard@...dia.com>, <jrdr.linux@...il.com>,
        <linux-kernel@...r.kernel.org>, <madhuparnabhowmik10@...il.com>,
        <mporter@...nel.crashing.org>, <willy@...radead.org>
Subject: [PATCH] mm/gup: protect unpin_user_pages() against npages==-ERRNO

As suggested by Dan Carpenter, fortify unpin_user_pages() just a bit,
against a typical caller mistake: check if the npages arg is really a
-ERRNO value, which would blow up the unpinning loop: WARN and return.

If this new WARN_ON() fires, then the system *might* be leaking pages
(by leaving them pinned), but probably not. More likely, gup/pup
returned a hard -ERRNO error to the caller, who erroneously passed it
here.

Cc: Ira Weiny <ira.weiny@...el.com>
Cc: Souptick Joarder <jrdr.linux@...il.com>
Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
Signed-off-by: John Hubbard <jhubbard@...dia.com>
---

Hi Dan,

Is is OK to use your signed-off-by here? Since you came up with this.

thanks,
John Hubbard
NVIDIA

 mm/gup.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/mm/gup.c b/mm/gup.c
index e5739a1974d5..41d082707016 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -328,6 +328,13 @@ void unpin_user_pages(struct page **pages, unsigned long npages)
 {
 	unsigned long index;
 
+	/*
+	 * If this WARN_ON() fires, then the system *might* be leaking pages (by
+	 * leaving them pinned), but probably not. More likely, gup/pup returned
+	 * a hard -ERRNO error to the caller, who erroneously passed it here.
+	 */
+	if (WARN_ON(IS_ERR_VALUE(npages)))
+		return;
 	/*
 	 * TODO: this can be optimized for huge pages: if a series of pages is
 	 * physically contiguous and part of the same compound page, then a
-- 
2.28.0