[clang] [analyzer] MallocChecker: Recognize std::atomics in smart pointer suppression. (PR #90918)

via cfe-commits cfe-commits at lists.llvm.org
Mon May 6 19:41:22 PDT 2024


sharkautarch wrote:


> Yeah I think it's not sufficient to model the atomics. It's a good idea to model them anyway, but even when atomics aren't used (eg. the custom smart pointer never needed to be thread-safe), the fundamental problem is that we still don't know the _initial_ value of the reference count. In particular we can't refute the possibility that the original value was like `-1` or something.

I was actually thinking about something similar to that sort of conundrum, and I did have some ideas that don't involve whole program analysis:

- Track function/method calls that pass freeable pointers/references to freeable stuff that cross TU boundaries. 
 Maybe that would allow the analyzer to backtrack beyond the local TU, without having to try to analyze all of the TUs?

- Specifically for use-after-free FPs with reference counting implementations, with perhaps the exception of static variables, I imagine you'd have to have allocated memory for you do to a use-after-free on it. Maybe for classes/objects recognized as reference counting implementations, you'd ignore any weird edgecase for semi-cross-TU use-after-free analysis (only thing I could think of is if in one TU memory could be allocated and then the pointer to it is set to null, and somehow another TU still has a pointer to said memory and frees the memory, and then a third TU uses the memory after it is freed) 
 So, if you assume that memory has to have been allocated at some point (again only applicable for use-after-free analysis), you could assume that the reference count for said memory *should* have been more than zero at *some point*

https://github.com/llvm/llvm-project/pull/90918


More information about the cfe-commits mailing list