Hi Evgeny,
On Wed, Mar 23, 2022 at 04:15:42AM +0300, Evgeny Vereshchagin wrote:
> > I think that is a good idea. I really believe all the issues reported
> > by MSAN are bogus.
>
> They are but all those issues should be gone once
> https://github.com/google/oss-fuzz/pull/7422 and
> https://githu
Hi Mark,
>> I can also prevent OSS-Fuzz from reporting new bugs found by MSan
>> by setting the experimental flag
>>
>> From
>> https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers
>>> If you want to test a particular sanitizer to see what crashes it generates
>>> with
Hi Evgeny,
On Tue, Mar 22, 2022 at 07:59:57PM +0300, Evgeny Vereshchagin wrote:
> I can also prevent OSS-Fuzz from reporting new bugs found by MSan
> by setting the experimental flag
>
> From
> https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers
> > If you want to tes
Hi Mark,
>> So I took the fuzz-libelf.c and fuzz-libdwfl.c files from the oss-fuzz
>> repo, tweaked them so they have a normal main that takes one file
>> argument to try to replicate the reports. That found some "real"
>> issues I submitted patches for. Then I ran afl-fuzz on them locally
>> duri
Hi Mark,
> Great. Thanks for testing. All patches from the fuzz branch are now
> merged. My local fuzzer also hasn't found any new issues for almost 24
> hours now.
Thanks! I synced my fork with the elfutils repository and tonight it will be
sent
to Coverity. If anything pops up I'll report it.
Hi Evgeny,
On Mon, 2022-03-21 at 17:33 +0300, Evgeny Vereshchagin wrote:
> I tested the fuzz branch and I can confirm that all the issues
> reported by OSS-Fuzz found with ASan+UBSan are gone.
> I kind of lost track of them at some point but the following issues
> can no longer be triggered:
>
>
Hi Mark,
> I'll report back once I figure
> out why the unit tests are failing on Fedora Rawhide:
> https://copr-be.cloud.fedoraproject.org/results/packit/evverx-elfutils-72/fedora-rawhide-x86_64/03799633-elfutils/builder-live.log.gz
>
I tested the fuzz branch and I can confirm that all the issu
Hi Mark,
> So I took the fuzz-libelf.c and fuzz-libdwfl.c files from the oss-fuzz
> repo, tweaked them so they have a normal main that takes one file
> argument to try to replicate the reports. That found some "real"
> issues I submitted patches for. Then I ran afl-fuzz on them locally
> during th
Hi,
On Thu, Mar 17, 2022 at 02:30:49PM +0100, Mark Wielaard wrote:
> The following fixes should fix reading of some broken ar archives and
> misaligned access of the section zero Shdr for mmaped ELF files where
> the start of the Elf image is at some offset from the start of the
> map.
>
> [PATCH
Hi,
On Fri, Mar 18, 2022 at 10:26:16AM +0300, Evgeny Vereshchagin wrote:
> I think before looking at those reports it would make sense to
> figure out what they are supposed to test and how they were tested
> to make sure they don't produce false positives. If they weren't
> actually tested I thin
Hi
> Given that the new fuzz targets seem to just fail to compile with
> ```
> projects/elfutils/fuzz-libdwfl.c:48:10: error: unused variable 'res'
> [-Werror,-Wunused-variable]
> Dwarf *res = dwfl_module_getdwarf(mod, &bias);
> ^
> 1 error generated.
> ```
I've just opened https://gith
Hi
> If they weren't actually tested I think it would make sense to revert them to
> avoid getting auto-generated CVEs
> until they're in more or less good shape at least.
I've just opened https://github.com/google/oss-fuzz/pull/7401 to weed out some
false positives.
Given that they are "secur
Hi,
> I looked over the "ClusterFuzz-External via monorail" emails and found
> some "real" issues.
Given that the new fuzz targets seem to just fail to compile with
```
projects/elfutils/fuzz-libdwfl.c:48:10: error: unused variable 'res'
[-Werror,-Wunused-variable]
Dwarf *res = dwfl_module_get
13 matches
Mail list logo
