It's like, babby's first C code here. Complete with a textbook example of a buffer overflow. And there are TWO instances of this same code in the codebase. Ugh.

I will not be revealing the library until I have figured out how to disclose this to the vendor, or at the very least alerted distros. I don't know how long that will take though.

(This library is widely deployed in some capacity, but it's an example of needing custom, malicious hardware to trigger the bug. If you can do that though it's trivial to trigger.)

A story in 4 parts (but I'm still waiting for the fourth to be written):

If all goes well poorly I might be dropping this vuln earlier than expected.

Update: a week ago I got a reply saying "oh I've escalated this to the devs, I'll let you know more". Today, the issue got auto-closed. I reopened it and I got an email saying pretty much the same thing, but with the addition of something about sending me PGP keys. I'm gonna have to send an encrypted email, aren't I? I haven't done that in so long, ugh.

Only 83 more days until I get fed up and drop it publicly instead.

(It's not an exciting vuln in any sense, I am just frustrated with this library in general)

I haven't even managed to get somewhere to report it yet. 80 days.

It's trivial to fix, too. I already wrote a patch. I just need to get it to them somewhere where they can actually hold onto it until they can release a version and issue an advisory.

Since I still haven't managed to get in touch with a developer, I'm backdating day 0 to when I first attempted to contact support, which was January 30. This means the deadline is April 30. 70 days.