Missing fixed attribute in libucl bug about osv.dev HOT 14 OPEN

✨ Thank you for your interest in OSV.dev's data quality! ✨

Please review our FAQ entry on how to most efficiently have this addressed.

from osv.dev.

Same for https://osv.dev/vulnerability/OSV-2024-551, https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=69531 - missing fix revision

from osv.dev.

@jonathanmetzman are you able to provide any insights here into what happens from OSS-Fuzz's side?

from osv.dev.

Is there something you noticed that oss-fuzz did wrong? To me everything appears normal, it has a fixed revision.

from osv.dev.

I searched for the logs related to bug 6726871018438656 and only saw regressed bisect performed on Jan 18, but I cannot find any logs related to fixed bisect.

However, for bugs with fix available for example this one: https://osv.dev/vulnerability/OSV-2024-504, I can see both regressed and fixed bisect performed.

from osv.dev.

I searched for the logs related to bug 6726871018438656 and only saw regressed bisect performed on Jan 18, but I cannot find any logs related to fixed bisect.

However, for bugs with fix available for example this one: https://osv.dev/vulnerability/OSV-2024-504, I can see both regressed and fixed bisect performed.

Yes that seems like a bug. This does not seem like an issue on OSS-Fuzz side, but on the bisection side of OSV.

from osv.dev.

@jonathanmetzman are you able to confirm that a request to bisect the fixed version was made from OSS-Fuzz? We have no evidence of one ever being received. Is it possible to repeat that request?

from osv.dev.

I don't think oss-fuzz makes these sorts of requests. I'm not really sure what's being asked of me here.
As far as I know, osv is a consumer of OSS-Fuzz not the other way around.

from osv.dev.

Lets check with @oliverchang once he is back from vacation. It feels like OSV bisector should be periodically checking for unfixed bugs by looking at testcase.fixed attribute and then triggering a fixed bisection. I don't think we should be rely on OSS-Fuzz, but will let Oliver check on this.

from osv.dev.

OSS-Fuzz does actually request a bisection via https://github.com/google/clusterfuzz/blob/aeec8a904ab50ec4169ebcc6667b5505d037fce0/src/clusterfuzz/_internal/base/bisection.py#L47.

There have been repeated cases in the past where this doesn't come through for some reason.

There's a bunch of improvements that need to be made here (mainly #2043 being the architectural one). This would enable us to e.g. do the more reliable periodic check rather than rely on OSS-Fuzz to be reliably sending requests, in addition to better decoupling some of the OSS-Fuzz infra from osv.dev. I think we need to do this in late Q3/Q4 this year. I'll write something up in more detail.

from osv.dev.

In the meantime, I'll run a manual backfill tomorrow (didn't get to this today).

from osv.dev.

https://osv.dev/vulnerability/OSV-2024-22 and https://osv.dev/vulnerability/OSV-2024-551 now both have fixed attributes. The backfill is still running in case there are any other recent entries with this issue.

from osv.dev.

https://osv.dev/vulnerability/OSV-2024-22 and https://osv.dev/vulnerability/OSV-2024-551 now both have fixed attributes. The backfill is still running in case there are any other recent entries with this issue.

apart from the longer architectural change and manual backfills, is there any intermediate solution that can send multiple bisections (tasks distributed over days, like send 3 - one now, one scheduled after a day, one scheduled after 2 days) so even if one fails, other goes through. This is a pretty bad quality issue, so thought for an intermediate solution (extra bisections shouldn't hurt, and data will be complete most of the time?)

from osv.dev.

https://osv.dev/vulnerability/OSV-2024-22 and https://osv.dev/vulnerability/OSV-2024-551 now both have fixed attributes. The backfill is still running in case there are any other recent entries with this issue.

apart from the longer architectural change and manual backfills, is there any intermediate solution that can send multiple bisections (tasks distributed over days, like send 3 - one now, one scheduled after a day, one scheduled after 2 days) so even if one fails, other goes through. This is a pretty bad quality issue, so thought for an intermediate solution (extra bisections shouldn't hurt, and data will be complete most of the time?)

Pub/Sub should already do this via its own retry mechanism. It's possible that something is preventing OSS-fuzz from sending the request in the first place in these cases -- I'll take a closer look.

from osv.dev.