Check the length before doing the compare like we do a few lines below,
not the other way around. It's a false positive because the length is
capped well below the maximum object size but it's an easy fix.
Fixes the following warning:
test/test-poll-oob.c:94:19: warning: ‘strncmp’ specified bound
[18446744071562067968, 18446744073709551615] exceeds maximum
object size 9223372036854775807 [-Wstringop-overread]
If uv_spawn() fails after uv__handle_init() has been called, the handle
remains in loop->handle_queue. This causes use-after-free if the handle
is stack-allocated or freed, and a subsequent loop operation like
uv_walk() accesses it.
This follows the same pattern as uv_tcp_init_ex() which explicitly
removes the handle from the queue on error.
The initial FindFirstFile can fail with ERROR_FILE_NOT_FOUND, meaning
no matches (read: empty directory), which leaves dir_handle set to
INVALID_HANDLE_VALUE. Not an actual error, it just means no results.
I can't get FindFirstFile to work like that on regular file systems
but it's been reported that it does under sshfs-win and the MSDN
documentation clearly states it's possible. Handle it.
Fixes: https://github.com/libuv/libuv/issues/4952
Remove the microsecond truncation in uv__fs_to_timespec() function to enable
full nanosecond resolution support. The utimensat() system call already
supports nanosecond precision, so the artificial truncation to microseconds
is no longer necessary.
This allows file modification and access times to be set with full nanosecond
precision instead of being limited to microsecond resolution.
Fixes the TODO comment about removing the microsecond resolution limit.
Fetch file metadata by handle instead of by path, otherwise there is a
race window between fetching and acting on said metadata where another
process can replace the file with another one.
There is still a potential race when upgrading the short path to a long
path but that that one is intrinsic. It's not something libuv can solve
except by refraining from calling GetLongPathName.
Fixes: https://github.com/libuv/libuv/issues/4568
The `flags` argument to `uv__udp_recvmsg_errqueue` was not initialized
in all code paths. Shuffle code around to make the control flow more
obvious (at the cost of a less legible diff.)
Also fixes an unused label warning when building on systems that aren't
Linux.
Introduced last month in commit 80a5e3ba0, "linux: add MSG_ERRQUEUE
ipv4/ipv6 udp support".
Add a stub function for no-ahafs builds. src/unix/core.c won't actually
call uv__ahafs_event but the linker still needs to see a symbol.
Like commit 87943b03 but for IBM i instead of AIX this time.
The test previously assumed a default nice value of 0, but this can vary
depending on PAM configuration, /etc/security/limits.conf, or other environment
settings.
Fixes: https://github.com/libuv/libuv/issues/4898
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
While unlikely that this fails (since it is implemented to call
`abort()` instead of actually return an error code, we would
theoretically leak this state. The process state init doesn't actually
have a cleanup, and just awkwardly relies on uv_signal_close being
unnecessary (which is likely true though).
There is a minor error about the return value of uv_cancel
for tasks that are already executing. All other parts of the
documentation correctly states that uv_cancel will fail.
_snwprintf_s takes its length argument in characters, not bytes.
Does not appear to be a security issue because the paths are not under
an attacker's control unless the system has been compromised beyond
salvation: requires a combination of being able to set the name of the
executable and/or changing %LOCALAPPDATA% or a registry key.
Refs: https://github.com/libuv/libuv/security/advisories/GHSA-jjrx-vr7q-7732
The static initial table reserved space for MxN elements but only used
every Nth element. Removing the excess elements shrinks the table 16x.
I added search/insertion/deletion time logging while here to ensure no
performance regressions.
Fixes: https://github.com/libuv/libuv/issues/4823
Rationale for changing it to an enum:
- frees up some bits that can be used for other things
- is potentially faster (direct vs. indirect call)
- is potentially more secure (makes UAF or overruns harder to exploit,
no arbitrary function pointer to clobber)
Fixes: https://github.com/libuv/libuv/issues/4842
