We found a division by zero bug in FFmpeg with a vibecoded fuzzer

ddclavijo about 3 hours ago 36 commentsRead Article on code.ffmpeg.org

DE version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

33% Positive

Analyzed from 788 words in the discussion.

Discussion (36 Comments)Read Original on HackerNews

dabinat•about 3 hours ago

It’s interesting how AI may both raise and lower the quality of software. It’s very easy to send an AI agent on an open-ended bug hunt, and if it wastes a bunch of time and effort and finds nothing, no big deal. Time is much more important for a human developer with a salary.

dmix•about 2 hours ago

Finding the bugs with LLMs is easy. Reviewing the output, cleaning it up, and making sure it doesn't break something else is the hard part.

nonethewiser•about 1 hour ago

No one can keep up with the volume of code AI produces.

We wont stop using AI.

We will use AI to check AI.

Of course this is crazy, but it will also unlock pretty insane scaling and productivity and ultimately we will manage it on either end via requirements and tests.

harambae•32 minutes ago

It's mostly (not entirely, but mostly) finding security issues in old human-written code. It'll eventually start running out of those.

From that standpoint, it's not a crazy setup security-wise. Maybe still crazy for development.

krona•41 minutes ago

You're suggesting that LLMs get better at fixing bugs/vulnerabilities, but at the same time stop getting better at finding them? What if this difference is inherent and essential?

hombre_fatal•about 1 hour ago

The missing part of this is that verifying the bug with LLMs is also easy, and so is adversarially reviewing the proposed fix with LLMs.

The only thing left for you to do should be directional decisions. The LLMs should pause and rope you in if the fix involves directional/invariant changes.

evenhash•about 2 hours ago

> It’s very easy to send an AI agent on an open-ended bug hunt, and if it wastes a bunch of time and effort and finds nothing, no big deal.

No big deal? It’s not like it’s free… tokens cost money.

rogerrogerr•33 minutes ago

Often rounds to free compared to human costs.

Supermancho•about 2 hours ago

I don't care if you call it an over-engineered looping machine or what, there are concrete benefits to using LLMs for this. They work faster than developing your own looping algorithm and more often produce useful results than not.

saghm•11 minutes ago

It's not even like fuzzers are valuable because of the process they use specifically either; the value is that they produce a concrete input that you can use as a reproducible test case at that point. The value could be produced by gazing into a crystal ball for all I care, as long as I can use what it gives me to reproduce a bug.

eviks•about 2 hours ago

But what's your expectation of the net?

shevy-java•about 2 hours ago

I dislike AI, but if AI finds real bugs then this is in my opinion objectively a positive thing. Of course the question is what constitutes a real bug.

hn_submit•34 minutes ago

A.I. is useful for this. But it would be even more useful if all new code were written in Rust or some other memory-safe language.

A.I. could also be used to port C/C++ codebases to Rust, which isn't economically feasible at the moment.

senderista•29 minutes ago

AI will have plenty of security bugs left to find in Rust codebases.

Spivak•8 minutes ago

I mean I get the sentiment but Rust won't save you against division by zero, it'll just panic at runtime like every other language.

pixl97•about 2 hours ago

Unfiltered models will help build exploits for the bugs they find, so there is some means of measuring their efficacy.

klipt•30 minutes ago

If you're just talking about security bugs.

There are also non security bugs that don't have exploits but just make the user experience worse.

ks2048•about 1 hour ago

No doubt fuzzers (vibecoded or otherwise) can be powerful, but can't you just mark all "/" as potential divide by zero errors?

I guess sometimes developers think they "know" some variable won't be zero, but unless it checked explicitly or by the compiler, that shouldn't be trusted.

Someone•about 1 hour ago

> but can't you just mark all "/" as potential divide by zero errors?

If you’re accepting large false positives rates: yes.

If you want users to take your warnings serious: no.

(Nitpick: you certainly don’t want to flag _all_ of them. Divisions by non-zero constants definitely should be excluded, for example (integer division by -1 can lead to overflow, but that would be a different warning))

saghm•about 1 hour ago

Fuzzers find inputs, not just "potential" errors that aren't triggerable.

dooglius•about 1 hour ago

What are you suggesting and how would it be different than how SIGFPE already works?

wvbdmp•about 1 hour ago

I mean there could be a guard clause? But yeah, seems like this could be statically evaluated like how some IDEs see a null check and don’t complain about nullability within the same scope.

robertlagrant•about 1 hour ago

What we need is a numeric type that cannot be zero.

winwang•23 minutes ago

Every day, we stray closer to Haskell. Dare I say it: good!

drdaeman•about 1 hour ago

What we need are refinement types, where there’s a base type and a predicate. F* has this:

     val (/) : int -> (divisor:int { divisor <> 0 }) -> int

rhdunn•36 minutes ago

It would be more flexible for a compiler to reuse the range analysis logic used in optimizations for statically verifiable divide by zeros. That way you could extend it to other things like statically verifiable overflows.

yeputons•30 minutes ago

And also cannot be INT_MIN, otherwise -1 / INT_MIN is undefined behaviour(!) in C and C++.

12j3afAv•about 2 hours ago

Generating an incorrect input file seems to be the easiest task of all for any fuzzer.

Generating correct input to get deep into the call stack and then finding something is the hard part.

Surac•about 2 hours ago

send patches

rs_rs_rs_rs_rs•about 2 hours ago

...they did.

ligarota•about 1 hour ago

Where?

They only suggested a basic guard, chich can be useless if this case never happens

VCFundedGenYer•about 2 hours ago

The fruits of using LLMs to code. You'll waste far more time finding what it quietly and subtly wrecked than you would have if you just coded it yourself.

jaggederest•about 2 hours ago

Those sneaky LLMs going 7 years into the past and committing as a human:

https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/8eda3c7f91e1a5b...

wiseowise•about 1 hour ago

It’s obviously Claude 69 with time travel functionality, that’s too dangerous to release to public. They’re working on space-time limiting sandbox to prevent these issues.

six_seven•about 1 hour ago

Its all fun and games until the Claude-who-remains hunts you down

jaggederest•31 minutes ago

Just remember kids, never immanentize the eschaton.

vegnus•about 2 hours ago

You're not reading it right. The bug was found using a vibecoded fuzzer.

12j3afAv•about 2 hours ago

I wonder from where Claude stole this fuzzer.

pjankiewicz•about 1 hour ago

Or it used something called an "analogy" which is a valid way to solve new problems.