Edit: And there was discussion about this back in 2024 as well
show comments
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.
show comments
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.
show comments
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.
show comments
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.
show comments
skupig
Am I missing something? Who cares? This isn't a security issue, it's just an unexploitable crash on bad data.
show comments
souvlakee
It is interesting that FFmpeg has its own Git server. Maybe we should move there too?
show comments
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.
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.
show comments
robertlagrant
What we need is a numeric type that cannot be zero.
show comments
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
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.
Surac
send patches
show comments
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.
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.
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.
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
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.
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.
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.
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.
Am I missing something? Who cares? This isn't a security issue, it's just an unexploitable crash on bad data.
It is interesting that FFmpeg has its own Git server. Maybe we should move there too?
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.
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.
What we need is a numeric type that cannot be zero.
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
I find it pretty cool that a fuzzer thrown together this way actually found a bug in ffmpeg
The README for the fuzzer is an AI slop mess. https://github.com/daedalus/fuzzer/
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.
send patches
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.
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.
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.