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

dabinat

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.

VCFundedGenYer

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.

Surac

send patches

12j3afAv

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.

ks2048

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.

robertlagrant

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

souvlakee

It is interesting that FFmpeg has its own Git server. Maybe we should move there too?

cpriest

Nice find. The interesting part isn't "AI wrote the fuzzer." It's that a cheap random harness still hits classical bugs in ancient parsers. Keep the corpus; throw away the hype.

jeffbee

I imagine the discussion will center around this application of AI, but to me this is just the Nth proof of the proven fact that you must build ffmpeg, if you insist on using it, with only an allow-list of file formats that you expect to encounter, and not with the kitchen sink of stuff you are never going to need.

tensegrist

note that this seems to be a bug in what i expect (feel free to correct me) is a code path for a little-used codec maybe we'll just see them remove support for these long-tail formats the way linux has been removing drivers for similar reasons https://www.phoronix.com/news/Linux-Retiring-Moxa-Driver

cptroot

This is not a real bug in FFmpeg. This is a demonstration that if you control a custom AVIO module it is possible to crash FFmpeg by giving it bad data.

justonenote

Whatever about the specifics of this bug and whether its a useful vector, this is not surprising even in the slightest? My current opinion on LLMs is that they are superhuman in that they lack fatigue, they have close to full knowledge across all subjects which are known to humans at least publicly, and the fact that you can vibe code a harness to look for bugs in a famously complicated C codebase is intern level stuff and hardly news. Smart aspiring blackhats will be targeting tmux next, both with light llm jailbreaks, light supply chain attacks (web search results) and LPEs within certain environments which weren't particularly useful before but with agents running on auto mode for hours become a very valuable springboard. I'm not sure on the quality of tmux code but I know its written in C and is very complex and was not at all designed to defend against this type of threat.

skupig

Am I missing something? Who cares? This isn't a security issue, it's just an unexploitable crash on bad data.

aeyes

A patch for this was submitted in April: https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.o... Edit: And there was discussion about this back in 2024 as well

BikiniPrince

Funny thing, I know I'm brushing up against something in gStreamer developer, but Fable flips out. I have only a loose idea where the issue might be lurking. Next week, I'll apply for the cyber and I suspect I'll find something similar. Right now, it's just annoying and thanks the OpenAI cyber was much easier to get access to.

1saadcodes

I find it pretty cool that a fuzzer thrown together this way actually found a bug in ffmpeg

driverdan

The README for the fuzzer is an AI slop mess. https://github.com/daedalus/fuzzer/

Zebfross

Why submit an issue rather than just making the fix and adding the tests in PR? Seems like they're just making work for the maintainers.