Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

code.ffmpeg.org

Post reply on HN
Print view View original

101–110 of 274 posts

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

#101

Post by [deleted] »

senordevnyc wrote: post #90
justonenote wrote: post #88

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 stu…

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 It seems like this would have been pure fantasy not that long ago though. So why isn’t it noteworthy again? I don’t really follow what you’re complaining about.

[deleted]

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

#102

Post by [deleted] »

jonhohle wrote: post #98
justonenote wrote: post #88

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 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 additiona…

[deleted]

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

#103

Post by macless »

dmix wrote: post #4
dabinat wrote: post #2

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.

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.

[flagged]

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

#104

Post by [deleted] »

jonhohle wrote: post #98
justonenote wrote: post #88

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 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 additiona…

[deleted]

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

#105

Post by nh2 »

inigyou wrote: post #94
_jackdk_ wrote: post #77

Earlier quoted context omitted.

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.

In Haskell they are a little less annoying. It is just easier to reason about (including proving) pure functions.

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

#106

Post by black_knight »

_jackdk_ wrote: post #77
astrange wrote: post #67

Earlier 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…

Definitely room for improvement on Haskell's standard library when it comes to the number-related type classes. Modern Haskell could do very well in this area with a good type-class redesign in this area. The issue I think is that this would invalidate a lot of existing code, relying upon that. But you can already replace Prelude with something else in your own code if you want to.

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

#107

Post by UltraSane »

black_knight wrote: post #59
dmix wrote: post #4

Earlier quoted context omitted.

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.

This is where I believe strong typing (like, Haskell-strong or stronger) and functional programming in general will be a win. The confidence I have that my fixes are localised when fixing Haskell code is infinitely stronger than fixing even Java, not speak about C, code.

Even Lean 4 strong typing

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

#108

Post by semiquaver »

aeyes wrote: post #91

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

Oddly enough I can’t access that site, it just heats up my phone solving hashes. Gave up after about a minute and anubis had only made it less than halfway through.

I doubt the real bots have any trouble bypassing it.

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

#109

Post by demibabs »

semiquaver wrote: post #108
aeyes wrote: post #91

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

Oddly enough I can’t access that site, it just heats up my phone solving hashes. Gave up after about a minute and anubis had only made it less than halfway through. I doubt the real bots have any trouble bypassing it.

Yeah, is it trying to mine bitcoin or something? Anubis usually takes a second but here I waited a minute and got 20% through on a modern phone.

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

#110

Post by [deleted] »

hombre_fatal wrote: post #33
dmix wrote: post #4

Earlier quoted context omitted.

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.

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.

[deleted]
Post reply on HN