Date: Thu, 8 Feb 2018 12:21:00 -0800 From: Matthew Wilcox <willy@...radead.org> To: Daniel Micay <danielmicay@...il.com> Cc: Jann Horn <jannh@...gle.com>, linux-mm@...ck.org, Kernel Hardening <kernel-hardening@...ts.openwall.com>, kernel list <linux-kernel@...r.kernel.org>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com> Subject: Re: [RFC] Warn the user when they could overflow mapcount On Thu, Feb 08, 2018 at 02:48:52PM -0500, Daniel Micay wrote: > I guess it could saturate and then switch to tracking the count via an > object pointer -> count mapping with a global lock? Whatever the > solution is should probably be a generic one since it's a recurring > issue. I was thinking of saturating _mapcount at 2 billion (allowing _refcount the extra space to go into the 2-3 billion range). Once saturated, disallow all attempts at mapping it until _mapcount has gone below 2 billion again. We can walk the page->mapping->i_mmap tree and find tasks with more than, say, 10 mappings each, and kill them. Now that I think about it, though, perhaps the simplest solution is not to worry about checking whether _mapcount has saturated, and instead when adding a new mmap, check whether this task already has it mapped 10 times. If so, refuse the mapping. Now we can argue that since pid_max is smaller than 400 million that _mapcount will never overflow, and so we don't need to check it. Convincing argument?
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ