I was looking at the reference counting logic for dynamically allocated strings and noticed that Atom::clone unconditionally increments ref_count without checking for overflow.
In src/atom.rs , the Clone implementation for Atom does a fetch_add(1, SeqCst) on the AtomicIsize . It seems like if a program were to clone an Atom enough times (e.g., isize::MAX times, which might be reachable on 32-bit platforms), the counter would wrap around to a negative value.
If the count wraps around, subsequent Drop calls might eventually cause the count to hit 1 and then 0 , which would trigger drop_slow(self) and deallocate the string memory. However, there would still be active Atom instances pointing to that memory, which could potentially lead to a Use-After-Free.
Despite being unlikely to occur in practice, the fix should be easy and without real tradeoffs.
I was looking at the reference counting logic for dynamically allocated strings and noticed that
Atom::cloneunconditionally incrementsref_countwithout checking for overflow.In
src/atom.rs, theCloneimplementation forAtomdoes afetch_add(1, SeqCst)on theAtomicIsize. It seems like if a program were to clone an Atom enough times (e.g.,isize::MAXtimes, which might be reachable on 32-bit platforms), the counter would wrap around to a negative value.If the count wraps around, subsequent Drop calls might eventually cause the count to hit 1 and then 0 , which would trigger
drop_slow(self)and deallocate the string memory. However, there would still be active Atom instances pointing to that memory, which could potentially lead to a Use-After-Free.Despite being unlikely to occur in practice, the fix should be easy and without real tradeoffs.