Date: Thu, 8 Feb 2018 11:42:35 -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:33:58PM -0500, Daniel Micay wrote: > I don't think the kernel can get away with the current approach. > Object sizes and counts on 64-bit should be 64-bit unless there's a > verifiable reason they can get away with 32-bit. Having it use leak > memory isn't okay, just much less bad than vulnerabilities exploitable > beyond just denial of service. > > Every 32-bit reference count should probably have a short comment > explaining why it can't overflow on 64-bit... if that can't be written > or it's too complicated to demonstrate, it probably needs to be > 64-bit. It's one of many pervasive forms of integer overflows in the > kernel... :( Expanding _mapcount to 64-bit, and for that matter expanding _refcount to 64-bit too is going to have a severe effect on memory consumption. It'll take an extra 8 bytes per page of memory in your system, so 2GB for a machine with 1TB memory (earlier we established this attack isn't feasible for a machine with less than 1TB). It's not something a user is going to hit accidentally; it is only relevant to an attack scenario. That's a lot of memory to sacrifice to defray this attack. I think we should be able to do better.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ