//sourceware.org/git/?p=elfutils.git;a=commit;h=64ee2cb792e7b6ba6ad2a5759bff7ce8714e4668
it seems apart from OSS-Fuzz elfutils is fuzzed elsewhere. Aleksei I
wonder if it would
be possible to add those fuzz targets to OSS-Fuzz? There are blind
spots there and I think it would be
really great to start covering at least some of them.
Thanks,
Evgeny Vereshchagin
etmodules.c:86)
==1373524== by 0x40954A: process_file (readelf.c:926)
==1373524==
./src/readelf: cannot get debug context descriptor: No DWARF information found
```
Thanks,
Evgeny Vereshchagin
eed missing on "i386" but I think it's fine
because it doesn't affect the fuzz targets in any way. They only need
the static libraries
from libdw, libelf and so on.
Thanks,
Evgeny Vereshchagin
no no-undefined trick independent of compiler used.
I'll try to figure out how it can be done. Apart from OSS-Fuzz (which
I think is a corner case in a way)
It should hopefully make `--enable-sanitize-*` work with clang.
Thanks,
Evgeny Vereshchagin
-Fuzz (where I
can't pass `--enable-sanitize-*`) and avoid
build failures like that going forward. It was discussed in
https://sourceware.org/pipermail/elfutils-devel/2021q4/004418.html
but didn't go anywhere though.
Thanks,
Evgeny Vereshchagin
h makes it kind of hard to read
passwords, tokens and so on and then expose them).
Thanks,
Evgeny Vereshchagin
lse positive. Looking at
https://github.com/google/oss-fuzz/issues/8497 it seems it should be
possible
to turn it off eventually.
Thanks,
Evgeny Vereshchagin
.ssh/id_rsa ?
I don't think it can be exploited to expose stuff that shouldn't be exposed.
Thanks,
Evgeny Vereshchagin
address in elf_cvt_gnuhash):
> https://sourceware.org/pipermail/elfutils-devel/2022q1/004782.html
> https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=fuzz
I rebased it on top my "fuzzing" branch and the fuzzers, static analyzers, the
unit tests
on various architectures and so on confirmed that the issue is gone. Thanks!
Thanks,
Evgeny Vereshchagin
rticular sanitizer to see what crashes it generates
> without filing them in the issue tracker, you can set an experimental flag
It should help to figure out whether it makes sense to keep it without spamming
the mailing list
in the process. What do you think?
Thanks,
Evgeny Vereshchagin
were built to make sure "static" builds are intact;
* the fuzz target was built and run with ClusterFuzzLite to make sure
it's still compatible with OSS-Fuzz;
* the code was analyzed by various static analyzers to make sure new alerts
aren't introduced.
Signed-off-
I'll report it.
> Yeah that is:
> https://systemd.io/COREDUMP_PACKAGE_METADATA/
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
That looks familiar. As far as I can remember fuzz-dwfl-core was introduced to
fuzz that
part of systemd.
Thanks,
Evgeny Vereshchagin
ointed
the tests to the master branch they also
failed. Looking at "phdr[8]: unknown object file note type 3405650558 with
owner name 'FDO' at offset 200" it seems
it's caused by the toolchain used there. On Fedora 35 the tests pass.
Thanks,
Evgeny Vereshchagin
ll be closed and I'll take
a look at what's left
there.
Thanks,
Evgeny Vereshchagin
ated.
> ```
I've just opened https://github.com/google/oss-fuzz/pull/7408 where the fuzz
targets are built with -Werror -Wall -Wextra
among other things.
Thanks,
Evgeny Vereshchagin
es.
Given that they are "security" issues and bash scripts generating CVEs rely on
that label I hope they will be closed
as "invalid" or "wonfix". The issues found by fuzz-elf-get-sections (which was
renamed to fuzz-libelf apparently) were
closed as "Verified&qu
agree it doesn't seem to make much sense to
make ASan happy here.
Thanks,
Evgeny Vereshchagin
libelf/elf_begin.c:852
```
(In this particular case it's a false positive because in practice it's safe to
pass strings like that there though)
Thanks,
Evgeny Vereshchagin
NED off with UBSan there (and tested it in
https://sourceware.org/bugzilla/show_bug.cgi?id=28720).
Thanks,
Evgeny Vereshchagin
make sure "static" builds are intact;
* the fuzz target was built and run with ClusterFuzzLite to make sure
it's still compatible with OSS-Fuzz;
* the code was analyzed by various static analyzers to make sure new alerts
aren't introduced.
Signed-off-
Hi Mark,
I'm not subscribed to the mailing list so I can't seem to reply to
https://sourceware.org/pipermail/elfutils-devel/2021q4/004595.html directly.
All those issues can be reproduced by downloading public testcases and
passing them to ./fuzz/dwfl-core. That particular issue can be reproduced
t;static" builds are intact;
* the fuzz target was built and run with ClusterFuzzLite to make sure
it's still compatible with OSS-Fuzz;
* the code was analyzed by various static analyzers to make sure new alerts
aren't introduced.
Signed-off-by: Evgeny
's still compatible with OSS-Fuzz;
* the code was analyzed by various static analyzers to make sure new alerts
aren't introduced.
Signed-off-by: Evgeny Vereshchagin
---
ChangeLog | 4 +
configure.ac
Hi Mark,
> Once you
> have the bytes you can simply call Elf *elf_memory (char *__image,
> size_t __size), There is no need to first write out the image to disk
> and then use a file descriptor to read it back in.
I think I should have mentioned in the commit message that the fuzz
target came fr
arious static analyzers to make sure new alerts
aren't introduced.
Signed-off-by: Evgeny Vereshchagin
---
tests/.gitignore | 1 +
tests/ChangeLog| 5 ++
tests/Makefile.am | 20 -
tes
is fine.
The rationale behind those checks (and why they are enabled by default) can be
found
at https://reviews.llvm.org/D67122. My understanding is that code with that
kind of UB
is known to be miscompiled from time to time.
Thanks,
Evgeny Vereshchagin
Hi Mark,
> But it would help if you replied to the original
> reviews and/or mentioned how the different versions of your patch have
> changed since the last time.
I did but it looks like those emails didn't pass the spam filter. I'll try to
figure out what happened there. Sorry about that!
>
k && make distcheck`. --no-undefined and -z,defs
are still passed by default as expected.
Signed-off-by: Evgeny Vereshchagin
---
ChangeLog | 5 +
configure.ac | 31 ++-
debuginfod/Makefile.am | 2 +-
libasm/Makefile.am | 2 +-
with both gcc and clang with and without ASan/UBsan
and running `make check && make distcheck`. --no-undefined and -z,defs
are still passed by default as expected.
Signed-off-by: Evgeny Vereshchagin
---
ChangeLog | 5 +
configure.ac | 31 ++-
th gcc and clang with and without ASan/UBsan
and running `make check && make distcheck`. --no-undefined and -z,defs
are still passed by default as expected.
Signed-off-by: Evgeny Vereshchagin
---
ChangeLog | 5 +
configure.ac | 31 ++-
30 matches
Mail list logo
