IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The orignal reproducer from oss-fuzz depends on the hostname (via %H and %c).
The hostname needs a dash for msan to report this, so a simpler case from
@evverx with the dash hardcoded is also added.
The issue is a false positive from msan, which does not instruct stpncpy
(https://github.com/google/sanitizers/issues/926). Let's add a work-around
until this is fixed.
We have only three bits of space, i.e. 8 possible classes. Immediately reject
anything outside of that range. Add the fuzzer test case and an additional
unit test.
oss-fuzz #6908.
We probably should allow very deep calls of our recursive functions. Let's add
a limit to avoid resource exhaustion. 240 is 10 per hour (if somebody is using
this for time based triggers...), so it should be more than enough for most use
cases, and is conveniently below the 250 stack limit in msan.
oss-fuzz #6917.
gmtime_r() will return NULL in that case, and we would crash.
I committed the reproducer case in fuzz-regressions/, even though we don't have
ubsan hooked up yet. Let's add it anyway in case it is useful in the future. We
actually crash anyway when compiled with asserts, so this can be easily
reproduced without ubsan.
oss-fuzz #6886.
This seems to be a false positive in msan:
https://github.com/google/sanitizers/issues/767.
I don't see anything wrong with the code either, and valgrind does not see the
issue. Anyway, let's add the test case.
We don't have msan hooked up yet, but hopefully we'll in the future.
oss-fuzz #6884.
