Bad Binder: Android In-The-Wild Exploit (Project Zero)

Posted Nov 27, 2019 12:33 UTC (Wed) by mfuzzey (subscriber, #57966)
In reply to: Bad Binder: Android In-The-Wild Exploit (Project Zero) by rweikusat2
Parent article: Bad Binder: Android In-The-Wild Exploit (Project Zero)

Yes but I suspect the number of object types that are allocated by kmalloc() is much greater than the number of size classes used.

So that solution would likely have a higher overhead maintaining more free lists. And freelists of infrequently allocated objects would probably waste space.

But I'm not a MM expert so maybe it's optimizable.

Also introducing something like that would be a pretty huge tree wide change due to the need to pass the object type.
Though I suppose it could be done bit by bit with some macro magic assistance.

Bad Binder: Android In-The-Wild Exploit (Project Zero)

Posted Nov 27, 2019 13:02 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link]

The original slab allocator, as conceived by Jeff Bonwick, was a generalized way to allocate typed objectes and cache already initialized but currently unused objects for future reuse. And that's what the slab/ slub/ slob allocators in Linux do as well. kmalloc is just a convenience interface on top of that which reintroduces size-based aggregation of memory chunks through the backdoor. And one drawback of this is that it means use-after-free errors are fairly easily exploitable because memory which used to hold some trusted information may be handed out to untrusted code to use as it sees fit while other trusted code still has a pointer to it.