On Fri, 2011-03-04 at 23:30 +0200, Pekka Enberg wrote: > Right. So you fill a slab with objects A that you want to overflow > (struct shmid_kernel in the example exploit) then free one of them, > allocate object B, smash it (and the next object), and find the > smashed object A. > > But doesn't that make the whole /slab/procinfo discussion moot? You > can always use brute force to allocate N objects (where N is larger > than max objects in a slab) and then just free nth object that's most > likely to land on the slab you have full control over (as explained by > Matt). > > Pekka This is a good point, and one that I've come to accept as a result of having this conversation. Consider the patch dropped, unless there are other reasons I've missed. I still think it's worth brainstorming techniques for hardening the kernel heap in ways that don't create performance impact, but I admit that the presence or absence of this debugging information isn't a crucial factor in successful exploitation. Thanks, Dan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>