Conversation

Linux kernel heap feng shui in 2022 An article by

and

describing the kernel changes that affected exploitation techniques for slab-related vulnerabilities over the last few years. duasynt.com/blog/linux-ker

232

Replying to

and

I believe the "post 5.0" part should be "post 5.9". Using separate caches for accounting was removed in this patch:

github.com

mm: memcg/slab: use a single set of kmem_caches for all allocations · torvalds/linux@10befea

Instead of having two sets of kmem_caches: one for system-wide and non-accounted allocations and the second one shared by all accounted allocations, we can use just one. The idea is simple: space ...

Replying to

and

👍 yes that needs to be 5.9 and prior to 5.14. and that's referring to kmem accounted general purpose allocations only

Replying to

Thanks for allowing us to improve github.com/nccgroup/explo :D

github.com

precision for mergeable cache vs accounting · nccgroup/exploit_mitigations@b4856b4

Replying to

Hmm, this looks wrong. The 5.9 and 5.14 changes did not affect the merging of kmalloc caches with special-purpose ones. Also, I don't think there were any changes wrt SLAB_ACCOUNT in 4.16? Merging was prevented by hardened usercopy.

Quote Tweet

Andrey Konovalov

@andreyknvl

Jun 9

Replying to @vnik5287 @linkersec and @poppop7331

Ah, so wrt kmalloc caches: they are not mergeable with non-kmalloc ones ever since 4.16 due to hardened usercopy, and these newer patches only affect whether GFP_KERNEL_ACCOUNT kmalloc allocations get dispatched into a different set of kmalloc caches than GFP_KERNEL ones. Right?

3:12 PM · Jun 9, 2022Twitter Web App

Replying to

Nice you spotted mistakes. I'll fix them once I can or feel free to do a PR if you fancy :)