Hacker News new | ask | show | jobs
by ulan 1459 days ago
I guess the authors used a raw allocation in the example code to show the simplest possible use-after-free.

Any software with complex object ownership written in a language without GC has to balance between user-after-free (freeing an object too early) and memory leaks (keeping an object alive longer than needed). Maybe constructing secure code here would mean simplifying object ownership, but that doesn't seem practical for a beast such a modern browser with millions of lines of code.

MTE with the heap scanning sounds like a real solution for the user-after-free problem, not merely a mitigation. The trade-off is that the memory is not immediately freed, but the measured increase of only 1% is promising.

2 comments

https://smallcultfollowing.com/babysteps/blog/2022/06/15/wha... Gives a good example (in rust) of a case where complex object ownership could lead to a bug. The summary of the example there looks like:

- you have some AST object and want to lower it in the compiler into an intermediate representation

- you want to add some interesting parts of the AST to your state while lowering and refer to them later in the lowering process

- This seems fine: the AST is first created, then you lower to the intermediate representation, then you can destroy the AST, so while you’re doing the lowering, the AST objects should all be alive and therefore ok to store references to in the lowerer-state

- However there is some mostly unnoticed code that is roughly desugaring some syntax by constructing temporary AST nodes

- So your addition may have your state including references to these temporary nodes

- And those temporary nodes are freed shortly after being created rather than after the lowering is all done

- Giving a quite subtle use-after-free.

It isn't a complete solution because it does not address stack-allocated data but it is very very close to being a full solution.