> 1. When spraying, they make use of the fact that same arena is used for all struct of a similar sizes. This allows them to fill holes in arenas with arbitrary data, creating fake structs. Why not have arena per struct or at least per subsystem?
This would help, but it's hard to do for C: there's no type information when you do a malloc. XNU has a lot of C++ code in it that just (iOS 15) got separated kalloc heaps, so it's certainly something that can be done, but I'm not sure if Linux can adopt this easily.
> 2. Have some secret tag stored before each struct allocated in the arena. When freeing , check that tag is still intact. This should detect if there was a write spanning multiple adjacent structs.
I'm not familiar with kernel allocator hardening, but the post mentions some kind of freelist protections. In general, you can detect some heap corruptions, but not all of them; the better you get the worse performance you have, usually.
> 3. I didn't quite understand how they managed to create malicious release function. They have control over buffer where they can write code, but memory page containing that buffer isn't executable, right?
No new code is introduced, the function pointer is pointed at a JOP chain.
This would help, but it's hard to do for C: there's no type information when you do a malloc. XNU has a lot of C++ code in it that just (iOS 15) got separated kalloc heaps, so it's certainly something that can be done, but I'm not sure if Linux can adopt this easily.
> 2. Have some secret tag stored before each struct allocated in the arena. When freeing , check that tag is still intact. This should detect if there was a write spanning multiple adjacent structs.
I'm not familiar with kernel allocator hardening, but the post mentions some kind of freelist protections. In general, you can detect some heap corruptions, but not all of them; the better you get the worse performance you have, usually.
> 3. I didn't quite understand how they managed to create malicious release function. They have control over buffer where they can write code, but memory page containing that buffer isn't executable, right?
No new code is introduced, the function pointer is pointed at a JOP chain.