google
Missing fixed attribute in libucl bug
Describe the bug https://osv.dev/vulnerability/OSV-2024-22 is missing fixed attribute field.
Expected behaviour As per https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65868, this bug is fixed and should point to this fixed commit https://github.com/vstakhov/libucl/commit/d6e62ca904286d4762607099a17efb2119404d06
:sparkles: Thank you for your interest in OSV.dev's data quality! :sparkles:
Please review our FAQ entry on how to most efficiently have this addressed.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Same for https://osv.dev/vulnerability/OSV-2024-551, https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=69531 - missing fix revision
@jonathanmetzman are you able to provide any insights here into what happens from OSS-Fuzz's side?
Is there something you noticed that oss-fuzz did wrong? To me everything appears normal, it has a fixed revision.
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.
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.
@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?
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.
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.
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 https://github.com/google/osv.dev/issues/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.
In the meantime, I'll run a manual backfill tomorrow (didn't get to this today).
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.
https://osv.dev/vulnerability/OSV-2024-22 and https://osv.dev/vulnerability/OSV-2024-551 now both have
fixedattributes. 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?)
https://osv.dev/vulnerability/OSV-2024-22 and https://osv.dev/vulnerability/OSV-2024-551 now both have
fixedattributes. 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.