linux-kernel - [PATCH 1/3] mm/mincore: make mincore() more conservative

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]

Message-Id: <20190130124420.1834-2-vbabka@suse.cz>
Date:   Wed, 30 Jan 2019 13:44:18 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-api@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jann Horn <jannh@...gle.com>, Jiri Kosina <jkosina@...e.cz>,
        Dominique Martinet <asmadeus@...ewreck.org>,
        Andy Lutomirski <luto@...capital.net>,
        Dave Chinner <david@...morbit.com>,
        Kevin Easton <kevin@...rana.org>,
        Matthew Wilcox <willy@...radead.org>,
        Cyril Hrubis <chrubis@...e.cz>, Tejun Heo <tj@...nel.org>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Daniel Gruss <daniel@...ss.cc>,
        Vlastimil Babka <vbabka@...e.cz>,
        Jiri Kosina <jikos@...nel.org>
Subject: [PATCH 1/3] mm/mincore: make mincore() more conservative

From: Jiri Kosina <jkosina@...e.cz>

The semantics of what mincore() considers to be resident is not completely
clear, but Linux has always (since 2.3.52, which is when mincore() was
initially done) treated it as "page is available in page cache".

That's potentially a problem, as that [in]directly exposes meta-information
about pagecache / memory mapping state even about memory not strictly belonging
to the process executing the syscall, opening possibilities for sidechannel
attacks.

Change the semantics of mincore() so that it only reveals pagecache information
for non-anonymous mappings that belog to files that the calling process could
(if it tried to) successfully open for writing.

Originally-by: Linus Torvalds <torvalds@...ux-foundation.org>
Originally-by: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Andy Lutomirski <luto@...capital.net>
Cc: Dave Chinner <david@...morbit.com>
Cc: Kevin Easton <kevin@...rana.org>
Cc: Matthew Wilcox <willy@...radead.org>
Cc: Cyril Hrubis <chrubis@...e.cz>
Cc: Tejun Heo <tj@...nel.org>
Cc: Kirill A. Shutemov <kirill@...temov.name>
Cc: Daniel Gruss <daniel@...ss.cc>
Signed-off-by: Jiri Kosina <jkosina@...e.cz>
Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
---
 mm/mincore.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/mm/mincore.c b/mm/mincore.c
index 218099b5ed31..747a4907a3ac 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -169,6 +169,14 @@ static int mincore_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	return 0;
 }
 
+static inline bool can_do_mincore(struct vm_area_struct *vma)
+{
+	return vma_is_anonymous(vma) ||
+		(vma->vm_file &&
+			(inode_owner_or_capable(file_inode(vma->vm_file))
+			 || inode_permission(file_inode(vma->vm_file), MAY_WRITE) == 0));
+}
+
 /*
  * Do a chunk of "sys_mincore()". We've already checked
  * all the arguments, we hold the mmap semaphore: we should
@@ -189,8 +197,13 @@ static long do_mincore(unsigned long addr, unsigned long pages, unsigned char *v
 	vma = find_vma(current->mm, addr);
 	if (!vma || addr < vma->vm_start)
 		return -ENOMEM;
-	mincore_walk.mm = vma->vm_mm;
 	end = min(vma->vm_end, addr + (pages << PAGE_SHIFT));
+	if (!can_do_mincore(vma)) {
+		unsigned long pages = (end - addr) >> PAGE_SHIFT;
+		memset(vec, 1, pages);
+		return pages;
+	}
+	mincore_walk.mm = vma->vm_mm;
 	err = walk_page_range(addr, end, &mincore_walk);
 	if (err < 0)
 		return err;
-- 
2.20.1