For those with difficulty accessing:

- - -

From: Anthony Hurtado <[redacted since hn has no scrape protection]>

vpk_read_packet() divides vpk->last_block_size and (par->block_align - vpk->last_block_size) by par->ch_layout.nb_channels without checking for zero.

While vpk_read_header() validates nb_channels > 0, the codec parameters may become zero through format probing misidentification (VPK probe score is 2/3 of AVPROBE_SCORE_MAX) or codec parameter reset, causing SIGFPE.

Fix by:

- Checking nb_channels != 0 before division in vpk_read_packet

- Returning EOF for empty last blocks (last_block_size == 0)

- Validating block_count > 0 in vpk_read_header

- Validating last_block_size <= block_align in vpk_read_header

Found by fuzzing with libFuzzer + AddressSanitizer. Reproduces with 10 distinct inputs.

[patch redacted for brevity]

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.

A patch was submitted, but apparently not merged. That was also my experience trying to submit a patch for https://trac.ffmpeg.org/ticket/8738 . Somebody on the bug tracker took note, but was apparently unable to effect a merge in the intervening years.

Maybe now that ffmpeg is using Forgejo, the ball won't be dropped like this as often. Or there'll just be a five-digit number of open pull requests instead.

what the fuck is that anime catgirl bollocks

> 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))

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

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

If it's possible for program execution with some particular input to lead to a divide-by-zero, that's a bug, especially if the program is expected to be able to handle malformed inputs, or perhaps even deliberately malicious ones. It's not trivial to determine whether a program does this correctly. If it was, program analysis would be easy.

Division can 'go wrong' for certain inputs, but it's not just division. In C, signed integer addition, subtraction, and multiplication, all give undefined behaviour on overflow.

As 'Someone' already pointed out, it's not helpful to just flag all uses of the division operator, or of other potentially dangerous operators. Minimising false positives is one of the core challenges of program analysis.

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.

No, you're not. It's a minor bug, probably with an easy fix, that deserves to be fixed. It's not worthy of front page HN...

everyone knows HN only accepts security write-ups /s

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.

Lots of projects run their own git or forgejo or similar. I run my own private forge, and it has a higher uptime than GitHub. (A shockingly low bar, tbh)

It’s surprisingly simple to setup, and the hardware requirements are pretty small for a private or small forge, as it’s usually a relatively small number of users/repos/etc.

You can add several remotes to your git, and I'd recommend you do so.

> 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 the LAN PLZ KTHX".

The result is going to be more stable than Github and, arguably, more secure too.

OP here: A bug report just needs a proof of existence for the condition while a bug fix needs a proof of correctness. Sometimes is the best to let the developers who are day to day in the codebase to choose the best fix and if they what to fix it.

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.

OP here: You are welcome to send a PR if you like. I'll be grateful if someone makes the readme more human.

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

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

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

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 runtime checks (be it software or hardware)... which is why processors already throw exception interrupts when division by zero is attempted.

...they did.

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

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

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

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.

If finding the bugs with LLMs is easy. Then making sure it doesn't break something else is just LLMs finding no bugs. Easy.

That hasn’t been that bad. My real issue has been the time sink involved in following along with the maintainer and jumper through their hoops. Even after I demonstrate a flaw and a potential fix. My schedule is just so busy I need to pencil in time to deal with them.

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.

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.

My plan for bigger things is mostly:

Generate multiple solutions- they do not to work 100% correctly. And than I check which I would prefer. Which is more to our applications taste.

And than I would take the vibe output as a kind of a ‚plan‘ which I use to implement but not follow 100% and at the end I take my solution and review it. I gain speed with that because I often can quickly see the pros and cons of a solution way better than when I would manually do it and hang on a major roadblock and also I even see such roadblocks in the vibe output - it’s mostly the part with an unnecessary amount of new code that looks nonsensical.

Using a LLM whose output is slowed to the rate of a human programmer as a pair programming partner is a very interesting experience.

I had the same knee-jerk reaction. "Did I read that correctly?"

But yeah, I guess it can be used to increase certain aspects of quality by letting them go wild. But I think I mostly hear about security or crash issues. In my experience they don't outweigh the number of other issues they cause. Like UI bugs. I've seen more than one service constantly rolling out features that are completely broken, just to have a completely new, still broken, solution available the next day.

Often rounds to free compared to human costs.

When talking about LLM tokens the cost is almost always being implicitly compared to very expensive human developer time.

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.

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

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.

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.

as I mentioned in another sibling, its because it's a very common denominator in high value targets. I didn't know its legacy was from OpenBSD but I really doubt that that helps it much in this scenario, when I say LPE I'm not talking about user to root elevation, I'm talking parsed text/control sequences to arb code execution in the user context. These will slip past llm classifiers as safe and I'm fairly sure that they are extremely common in codebases like tmux, despite them having strong security posture its just a threat that was previously a bit outlandish and not accounted for.

persisted malicious code running in your tmux process that you don't know about is probably not where you want to be, for obvious reasons.