[clang] [LifetimeSafety] Add UseFacts for function arguments and assignment RHS (PR #180446)
Utkarsh Saxena via cfe-commits
cfe-commits at lists.llvm.org
Mon Feb 9 04:57:42 PST 2026
================
@@ -260,9 +260,22 @@ void PointerToVectorElement() {
}
void SelfInvalidatingMap() {
- std::unordered_map<int, int> mp;
- mp[1] = 1;
- mp[2] = mp[1]; // FIXME: Detect this. We are mising a UseFact for the assignment params.
+ std::unordered_map<int, std::string> mp;
+ // TODO: We do not have a way to differentiate between pointer stability and iterator stability!
+ // std::unordered_map and other containers provide pointer/reference stability. Therefore the
+ // following is safe in practice.
+ // On the other hand, std::flat_hash_map (since C++23) does not provide pointer stability on
+ // insertion and following is unsafe for this container.
+ mp[1] = "42";
+ mp[2] = mp[1]; // expected-warning {{object whose reference is captured is later invalidated}} \
----------------
usx95 wrote:
This is interesting indeed. The needed UseFact here is not that of a `DeclRefExpr`. Here is the sequence of events for `mp[2] = mp[1]`(assuming C++17 and above where RHS is evaluated before LHS).
1. `mp[1]` (RHS)
2. `mp[2]` (LHS)
3. `operator=(std::string& LHS, const std::string& RHS)`
1. Gets the reference to existing value for key=`1`.
2. Inserts `2` in to the map and returns reference to the new empty string value. This also invalidates the reference from step 1.
3. operator= reads both references from step 1 and 2 and tries to assign LHS = RHS. This gives a UAF.
https://godbolt.org/z/s4fad3zrE
This cannot be dealt alone by DeclRefExpr as step 1 and 2 have origins associated to other kinds of expressions.
https://github.com/llvm/llvm-project/pull/180446
More information about the cfe-commits
mailing list