CVE-2026-84782

Range taken from the CVE record, check it before committing. make newentry in security/vuxml creates the vid.

  <vuln vid="FIXME (make newentry)">
    <topic>FIXME -- FIXME</topic>
    <affects>
      <package>
	<name>linux-c7-openssl-devel</name>
	<range><lt>1.0.2zs</lt></range>
      </package>
      <package>
	<name>openssl-unsafe</name>
	<range><lt>1.0.2zs</lt></range>
      </package>
    </affects>
    <description>
      <body xmlns="http://www.w3.org/1999/xhtml">
	<p>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.</p>
      </body>
    </description>
    <references>
      <cvename>CVE-2026-84782</cvename>
      <url>https://nvd.nist.gov/vuln/detail/CVE-2026-84782</url>
    </references>
    <dates>
      <discovery>2026-09-29</discovery>
      <entry>2026-10-25</entry>
    </dates>
  </vuln>