[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