CVE-2026-84782

Issue summary: The DTLS retransmission logic does not correctly handle

a handshake message write that is suspended part-way through.

The retransmitted message can be read past the message buffer and

the retransmission overwrites the internal state the suspended write

needs to resume correctly.

Impact summary: The retransmitted message can disclose a heap memory

to the peer as plaintext handshake data or cause a crash and a Denial

of Service when the read reaches an unmapped memory region.

CWE: CWE-125: Out-of-bounds Read

Description: DTLS handshake messages can be written out in multiple

fragments, and a write can suspend mid-message (returning WANT_WRITE)

if the underlying transport temporarily cannot accept more data. While

such a write is suspended, the DTLS retransmission timer may

independently fire and ask the retransmission logic to resend an

earlier, already-acknowledged-as-sent message from its retransmit

queue.

The retransmission logic reused the same internal buffer and position

tracking as the message that was still being written, without

resetting the position back to the start of the message being

retransmitted. As a result the retransmission was read starting from

wherever the suspended write had left off, producing a mislabelled

message whose body was leftover bytes from the other, larger message

still in flight - content that was never meant to be sent at that

point, and which could run past the end of the allocated buffer.

Separately, even when the retransmission is positioned correctly,

allowing it to run to completion while another write is suspended

overwrites the same shared bookkeeping that the suspended write

depends on to resume. When the application later resumes the

suspended write (via a subsequent SSL_read(), SSL_write(),

SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a

state inconsistent with the message and aborts the process in

a debugging build.

The fix resets the retransmission's read position to the start of the

message before resending, and skips retransmission entirely whenever a

handshake write is still suspended, deferring to the next call that

resumes it instead.

FIPS impact: no

The affected code is outside the FIPS module boundary.