ticket + length - ID_LEN

Where ID_LEN is 32 bytes. The only guard before that logic was:

if (length > 0) {

That's the problem.

What Actually Happens If someone provides a ticket smaller than 32 bytes, say 8 bytes:

length = 8

Then:

length - ID_LEN = 8 - 32 = -

Now the pointer becomes:

ticket - 24

So instead of reading from the actual ticket buffer, the code reads 24 bytes before it. That's an out-of-bounds read. Not a write. Not a crash guaranteed. But still undefined behavior. And in a crypto library, undefined behavior is not something you want anywhere near session handling.

Why This Matters Reading memory before a buffer means you're pulling in data that doesn't belong to that structure. Depending on the heap layout, that memory could contain:

• Other session data
• Heap metadata
• Possibly sensitive material

Even if it "just works" most of the time, it's still unsafe. And unsafe in crypto code is always high impact.

The Fix The patch changes:

if (length > 0)

To:

if (length >= ID_LEN)

That's it. Now length - ID_LEN can never go negative. No pointer underflow. No reading before the buffer. One character difference. Completely different safety guarantees.

How I Found It This wasn't dynamic fuzzing or a crash trace. It was just reviewing the logic and asking:

• What happens if this assumption is wrong?

Whenever you see:

length - constant

without an explicit >= constant check, it's worth looking closer. Sometimes the bug isn't complicated. It's just one missing boundary condition.

If you want, I can also help you add a clean timeline section + coordinated disclosure note so it looks fully professional when you publish.