The bug that was already fixed: a missing backport in libebml

TL;DR: While fuzzing the Matroska parser stack (libmatroska + libebml), I flagged a malformed-input path in EbmlMaster element reading that could drive a bogus, effectively unbounded read size. My minimized proof-of-concept turned out not to be a valid EBML file — the maintainer rightly pushed back — but the underlying concern was real in an unexpected way: an equivalent guard already existed on the v1.x branch and had never been forward-ported to master. The maintainer backported it as commit 372b681c3, crediting the report. It’s a small fix, but the story is a good one about coordinated disclosure: being wrong about the specifics and still being useful, and about a whole class of bug that lives in the gap between branches.

The setup

The Matroska/WebM container is a deeply nested EBML tree — elements with sizes, inside elements with sizes, for many levels. That’s a classic memory-safety and resource-exhaustion surface, and neither libmatroska nor libebml is in OSS-Fuzz or ships an in-repo fuzz harness, so I built one: a persistent-mode AFL++ harness that uses the library’s real memory callback and recursively reads the EBML header and Matroska semantic tree, under ASan/UBSan.

Most of what came out was noise that had to be characterized and discarded — a harness double-delete, a debug-only library assertion, and a genuinely-known fixed-lacing uint8_t wrap that upstream had already patched on v1.x but not master (foreshadowing). What stood out from timeout triage was a path where reading a child element could compute a size that made no sense for the bytes actually present.

Being wrong, usefully

Here’s the part worth being honest about. I minimized the input aggressively — the smaller the PoC, the sharper the root cause, usually. But EBML has a real header structure, and my minimized file had shed it. When I sent the report, maintainer Steve Lhomme pointed out two things in the same reply:

1. The minimized input isn’t a well-formed EBML file, so it isn’t valid evidence that a conforming reader reaches the path.
2. An equivalent guard for exactly this situation — “don’t keep reading when an upper element claims to end after its parent, because the remaining size goes negative” — already exists on the v1.x branch, as a commit that was never carried to master.

The right move there is not to argue. I withdrew the PoC as validation evidence in a signed reply and reclassified the report from “novel vulnerability” to “possible missing master backport, pending your assessment.” That reframing is the whole value: I was wrong about having a clean repro, but the observation that master was missing a guard its own maintenance branch already had was correct.

The bug class: fixes that don’t travel

This is the interesting bit. A “missing backport” (or missing forward-port) is a bug that exists purely because a fix landed on one branch and not another. The code was known to be wrong. Someone wrote the guard. It just never made the trip to the default branch that everyone actually builds from. There’s nothing to discover about the vulnerability itself — the fix is public, sitting in the git history of a sibling branch. What’s left is the diffing discipline to notice the gap.

If you’re hunting, this is a cheap, high-yield place to look: take a project with a stable/v1.x branch and a master, and diff the security-relevant files between them. Guards, bounds checks, and overflow fixes that exist on one side and not the other are latent bugs on whichever branch is behind — already root-caused, already fixed once, waiting for a forward-port. (The fixed-lacing wrap I mentioned above was a second instance of the same pattern in the same repo.)

Resolution

The maintainer forward-ported the guard to master as 372b681c3:

EbmlMaster: exit reading loop if upper element found ends after its parent … we shouldn’t use a MaxSizeToRead that would be negative. Missing backport to master Reported-by: Benjamin Ali (glitchfox)

It merged to master on 2026-07-24. No CVE was requested; this is an informational, robustness-hardening fix, and inflating it would be dishonest.

Takeaways

• When a maintainer corrects you, update the claim, don’t defend it. The report went from “here’s a crash” to “your master is missing a guard your v1.x has” — a smaller claim, but a true and actionable one, and it’s what landed the fix.
• Diff long-lived branches for security fixes that didn’t propagate. “Already fixed on the other branch” is a real and cheap bug class.
• Minimization has a floor. Shrinking a PoC past the format’s structural requirements produces something that reproduces your harness’s behavior but not a real consumer’s. For structured formats, keep the PoC a valid file.