On Tue, Jun 27, 2017 at 12:31 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > But I am not really sure I understand consequences of this patch. So how > do those attacks look like. Do you have an example of a CVE which would > be prevented by this measure? It's a regular practice, especially for heap grooming. You can see an example here: http://cyseclabs.com/blog/cve-2016-6187-heap-off-by-one-exploit which even recognizes this as a common method, saying "the standard msgget() technique". Having the separate caches doesn't strictly _stop_ some attacks, but it changes the nature of what the attacker has to do. Instead of having a universal way to groom the heap, they must be forced into other paths. Generally speaking this can reduce what's possible making the attack either impossible, more expensive to develop, or less reliable. >> This would mean building out *_user() versions for all the various >> *alloc() functions, though. That gets kind of long/ugly. > > Only prepare those which are really needed. It seems only handful of > them in your patch. Okay, if that's the desired approach, we can do that. > OK, I was about to ask about vmalloc fallbacks. So this is not > implemented in your patch. Does it metter from the security point of > view? Right, the HIDESYM-like feature hasn't been ported by anyone yet, so this hasn't happened. It would simply build on similar logic. -Kees -- Kees Cook Pixel Security -- 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>
