google / oss-fuzz

OSS-Fuzz - continuous fuzzing for open source software.
https://google.github.io/oss-fuzz
Apache License 2.0
10.38k stars 2.2k forks source link

Self-closing trust-dns issues #10857

Open djc opened 1 year ago

djc commented 1 year ago

For trust-dns, we've recently seen a bunch of issues that are opened by the bot and then closed a few days later, without there being any (relevant) activity in the repo. Any clue why this could be? It seems pretty unexpected?

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61513 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61350 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61381

cc @bluejekyll @manunio

bluejekyll commented 1 year ago

Thanks, @djc i was curious about this as well.

oliverchang commented 1 year ago

Our automation seems to think https://github.com/bluejekyll/trust-dns/compare/9e647103241a11082ffa7ff69489b8f1f683119b...3f9a68c15e76dc05739de22390eb58ec8ba43b16 fixed all 3. Are these all indeed relevant to the bugs linked?

djc commented 1 year ago

No, they are definitely irrelevant. Also, those fixes predate the issue by quite a bit...

oliverchang commented 1 year ago

No, they are definitely irrelevant. Also, those fixes predate the issue by quite a bit...

Is it possible that the dependency change in https://github.com/bluejekyll/trust-dns/compare/9e647103241a11082ffa7ff69489b8f1f683119b...3f9a68c15e76dc05739de22390eb58ec8ba43b16 caused the actual error surfaced to change? ClusterFuzz would consider that a different issue and potentially cause this closure.

Re the issue dates -- they actually were actually first seen a lot earlier (if you check the "Detailed report" links). We delayed in filing issues for them because there were other very similar open issues in the issue tracker already.

djc commented 1 year ago

The fuzz test only tests that parsing a DNS message works and round-trips correctly. The dependency change is for a dependency on the TLS protocol path which is not exercised by the fuzzer. The other commit is to the trust-dns-server crate which is not pulled in by the fuzzer (which only depends on trust-dns-proto).