From what I have just learned, the `global_allocator` attribute has some magic:

• it can be used anywhere to define a global allocator, even deep inside a private unused module of a dependency of a dependency
• the defined global allocator will be called implicitly, i.e., your crate will be affected if it has a dependency which defines the global allocator, even if your crate doesn’t call any function from that dependency
• as far as I know, there is no way to check what global allocator I’m using

So, I can imagine that a hacker makes a useful crate, and hides the global_allocator definition in somewhere, and do some bad in the implementation of alloc and dealloc, then a rust user finds the crate, checks the documents and source codes of the public function, feels good, calls the absolutly safe functions only, but the hacker still succeed doing the bad thing.

Maybe a lint to deny global_allocator in dependent crate can be added to rustc or clippy.

2 posts - 2 participants

Read full topic