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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
