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
We found a division by zero bug in FFmpeg with a vibecoded fuzzer
91–100 of 274 posts
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#92Whatever 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 stu…
I don’t think tmux is the most worthwhile target because you’d need the user to either execute code locally (thus negating any point in targeting tmux) or rely on the user curl or cat some compromised document (in which case you’re better off targeting curl or cat).
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#93It is interesting that FFmpeg has its own Git server. Maybe we should move there too?
You can add several remotes to your git, and I'd recommend you do so.
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#94Earlier quoted context omitted.
Haskell's type system would not easily prevent this bug. It's not good at numeric/logic issues like that. When people say "Haskell makes it impossible to write bugs" they mean "Haskell has enums" (ADTs).
Liquid Haskell might require you to prove that the divisor is nonzero, but even in standard Haskell there's common idioms for ensuring that a list is non-empty (data NonEmpty a = a :| [a]) or that text is non-empty (newtype NonEmptyText = NonEmptyText Text, with non-exported constructor, helpers like make :: Text -> NonEmptyText, or more advanced tricks like https://exploring-better-ways.bellroy.com/haskell-koan-type…
OOP has those too, and they're very annoying.
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#95Whatever 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 stu…
I don’t think tmux is the most worthwhile target because you’d need the user to either execute code locally (thus negating any point in targeting tmux) or rely on the user curl or cat some compromised document (in which case you’re better off targeting curl or cat).
the point is tmux is being used by many developers working in high value targets to automate long running unsupervised agent tasks. you don't need the user to execute code, you need _their agent_ to stumble on the wrong search result or github repo and it wont be noticed for hours that they loaded a persistent threat into your environment.
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#96This 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.
Not custom. It's an existing module for a format called VPK. It's a quite trivial bug though, not exploitable apart from DOS and won't ever happen in a real file.
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#97note 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
it's widely used but in "industry" applications. so ffmpeg is probably being used in a lot of offices (studios) and maybe even being included in end user software.
Understatement of the year. Almost everything that processes video uses ffmpeg.
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#98Whatever 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 stu…
Not that it doesn’t have issues, but I’m not sure why you’d choose tmux of all things. It runs as a user and has no privileges to escalate. It was written for and is part of OpenBSD and follows their security hardening practices.
(There actually was one privilege escalation bug in tmux, but it actually seems like a distro packaging error. The distro setgid the executable so the resulting shell inherited the additional group. This didn’t require any exploit, that’s just how child process inheritance works.)
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#99It is interesting that FFmpeg has its own Git server. Maybe we should move there too?
> It is interesting that FFmpeg has its own Git server. Maybe we should move there too? Git is a DVCS. I know many people only ever used Git through Github and forgot what the 'D' in DVCS means but whether or not they remember what the 'D' stands for, running your own Git server is trivial . Especially in this day and age of LLMs were you can just ask: "Clone this repo and convert it to base Git repo and serve it on…
If you have SSH access to a server and Git is installed on that server, you can use it as a Git server. No additional setup is required. The Git client knows how to log in and invoke the Git server over SSH.
Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer
#100What we need is a numeric type that cannot be zero.
The only way to achieve this is to either put a runtime software check on a variable whenever it's assigned/used, or to literally add hardware support in processors themselves which literally throws an interrupt when a "neverShallBeZero" variable is assigned to zero. There's no viable way to statically prove at compile-time that these variables will never become zero at runtime, ultimately forcing a system of endless…
It's possible, just extremely difficult.