[all-commits] [llvm/llvm-project] 7e5bc7: [libc++] Fix UB in filesystem::__copy for non-exis...

Afanasyev Ivan via All-commits all-commits at lists.llvm.org
Tue Jun 11 18:41:38 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7e5bc71514c7428ab791b187d5cbf8215afd5a87
      https://github.com/llvm/llvm-project/commit/7e5bc71514c7428ab791b187d5cbf8215afd5a87
  Author: Afanasyev Ivan <ivafanas at gmail.com>
  Date:   2024-06-11 (Tue, 11 Jun 2024)

  Changed paths:
    M libcxx/src/filesystem/operations.cpp

  Log Message:
  -----------
  [libc++] Fix UB in filesystem::__copy for non-existent destination. (#87615)

The lstat/stat/fstat functions have no guarantee whether the `struct stat`
buffer is changed or not on failure. The filesystem::__copy function assumes
that the `struct stat` buffer is not updated on failure, which is not
necessarily correct.

It appears that for a non-existing destination `detail::posix_lstat(to,
t_st, &m_ec1)` returns a failure indicator and overwrites the `struct stat`
buffer with a garbage value, which is accidentally equal to the `f_st` from
stack internals from the previous `detail::posix_lstat(from, f_st, &m_ec1)` 
call.

file_type::not_found is a known status, so checking against 
`if (not status_known(t))` passes spuriously and execution continues.
Then the __copy function returns errc::function_not_supported because stats
are accidentally equivalent, which is incorrect.

Before checking for `detail::stat_equivalent`, we instead need to make sure 
that the call to lstat/stat/fstat was successful.

As a result of `f_st` and `t_st` not being accessed anymore without checking 
for the lstat/stat/fstat success indicator, it is not needed to zero-initialize 
them.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list