[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