mirror of
https://github.com/llvm/llvm-project.git
synced 2025-04-27 15:56:07 +00:00
b0e19cfb62
Previously, assignment to a std::basic_string type with a _custom_ allocator could under certain conditions attempt to interpret part of the target string's "short" string-content as if it was a "long" data pointer, and attempt to deallocate a garbage value. This is a serious bug, but code in which it might happen is rare. It required: 1. the basic_string must be using a custom allocator type which sets the propagate_on_container_copy_assignment trait to true (thus, it does not affect the default allocator, nor most custom allocators). 2. the allocator for the target string must compare not equal to the allocator for the source string (many allocators always compare equal). 3. the source of the copy must currently contain a "long" string, and the assignment-target must currently contain a "short" string. Finally, the issue would've typically been innocuous when the bytes misinterpreted as a pointer were all zero, as deallocating a nullptr is typically a no-op. This is why existing test cases did not exhibit an issue: they were all zero-length strings, which do not have data in the bytes interpreted as a pointer.