[all-commits] [llvm/llvm-project] b0e19c: [libcxx] Don't deallocate non-pointer data in stri...

[James Y Knight via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b0e19cfb6205d7cf36aa0fc3cb395205f7dc36ba
      https://github.com/llvm/llvm-project/commit/b0e19cfb6205d7cf36aa0fc3cb395205f7dc36ba
  Author: James Y Knight <jyknight at google.com>
  Date:   2023-09-24 (Sun, 24 Sep 2023)

  Changed paths:
    M libcxx/include/string
    M libcxx/test/std/strings/basic.string/string.modifiers/string_assign/string.pass.cpp

  Log Message:
  -----------
  [libcxx] Don't deallocate non-pointer data in string assignment. (#67200)

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.