3 ms·

Wait, what calloc (3) no-longer zeros though? >Memory Allocation >Known Issues >The system memory allocator free operation zeroes out all deallocated blocks

by mzs 4y ago

Wait, what calloc (3) no-longer zeros though? >Memory Allocation >Known Issues >The system memory allocator free operation zeroes out all deallocated blocks in macOS 13 beta or later. Invalid accesses to free memory might result in new crashes or corruption, including NULL-pointer dereferences and non-zero memory being returned from calloc. (97449075) https://developer.apple.com/documentation/macos-release-notes/macos-13-release-notes https://developer.apple.com/documentation/macos-release-note... edit: I guess this is taking advantage of use-after-free being undefined behavior.

cesarb 4y ago
From what I understood, the trick is that, for a block which was returned by free() and later returned by calloc(), the former behavior was to zero within the calloc(), while the new behavior would be to zero within the free(). If there's a bug which writes to the memory after the free() but before the calloc(), the former behavior would mean it's still zeroed, but the new behavior would mean it ends up overwritten with something which isn't all-zeros.
syntheticnature 4y ago
I'm not sure I see it as "taking advantage of"; if code is engaging in the UB of writing to invalid pointers, there could still have a race condition where calloc() appears to be returning non-zeroed memory, simply because the invalid pointer write happened after the clear. This just moves the clear back in time.
monocasa 4y ago
calloc(3) isn't the only way to allocate memory, nor the most common one in ObjC apps.
- astrange 4y ago
  Actually, ObjC objects are allocated with calloc() so it might be the most common one. It also has a better interface than malloc() because it can check for overflow evaluating `size*count`, though it'd be even better if C had first-class types and you could pass that in.

3 ms·

Wait, what calloc (3) no-longer zeros though? >Memory Allocation >Known Issues >The system memory allocator free operation zeroes out all deallocated blocks

by mzs 4y ago

cesarb 4y ago
From what I understood, the trick is that, for a block which was returned by free() and later returned by calloc(), the former behavior was to zero within the calloc(), while the new behavior would be to zero within the free(). If there's a bug which writes to the memory after the free() but before the calloc(), the former behavior would mean it's still zeroed, but the new behavior would mean it ends up overwritten with something which isn't all-zeros.
syntheticnature 4y ago
I'm not sure I see it as "taking advantage of"; if code is engaging in the UB of writing to invalid pointers, there could still have a race condition where calloc() appears to be returning non-zeroed memory, simply because the invalid pointer write happened after the clear. This just moves the clear back in time.
monocasa 4y ago
calloc(3) isn't the only way to allocate memory, nor the most common one in ObjC apps.
- astrange 4y ago
  Actually, ObjC objects are allocated with calloc() so it might be the most common one. It also has a better interface than malloc() because it can check for overflow evaluating `size*count`, though it'd be even better if C had first-class types and you could pass that in.