Conversation

The main issue with ASan for bounds checking is that while it prevents a linear overflow such as with memcpy or strcpy, it doesn't prevent a non-linear overflow from reading or writing from another valid allocation. As you point out, it's based on tracking accessible memory.
1
For use-after-free, double-free, etc. it depends on a quarantine with a limited size. This can be scaled based on the amount of memory that you're able to accept using. The same kind of protection can be protected via a malloc implementation without the same kind of overhead too.
1
An attacker that's exploiting a vulnerability couldn't exploit a linear overflow. However they can still exploit a non-linear overflow and could often still exploit a use-after-free, which are the main 2 sources of memory corruption bugs. Linear overflows are way less common now.
1
With either ASan or HWAsan, they can only catch overflows between objects. They won't catch corruption within. HWAsan is a pretty close approximation of coarse (inter-object) heap safety with 1/256 chance to fail. ASan is very far due to entirely relying on redzones + quarantine.
1