OpenSSL: SSL_set_SSL_CTX mid-handshake leaves a stale slot count, allowing heap OOB read/write

Impact

A TLS connection sizes its per-slot certificate validity array from the SSL_CTX that created it. Replacing the context mid-handshake with SSL_set_SSL_CTX - the usual SNI virtual-host pattern - does not refresh that count, so if the replacement context knows about more provider TLS-SIGALG entries than the original, a signature algorithm offered by the peer can resolve past the end of the array. Processing those algorithms reads four bytes past the end per algorithm and, where the word read is zero, writes a fixed value over it, which can corrupt heap metadata and abort the process. For an operator that means a remotely triggerable crash of a multi-tenant TLS front end. The prerequisites are narrow: the two contexts must be aware of different numbers of provider signature algorithms (separate library contexts, a provider loaded in between, or default-vs-FIPS provider differences), TLS 1.3, and the server must have the matching certificate configured. Such a deployment also cannot negotiate those algorithms with legitimate clients, so the misconfiguration tends to be noticed; OpenSSL rates it Low.

Who can reach it

A remote unauthenticated TLS client connecting to a server that calls SSL_set_SSL_CTX during the handshake, typically from a servername callback. Applications that never call SSL_set_SSL_CTX are not affected.

What to do

Take the fixed OpenSSL release from the 2026-09-29 advisory and restart the TLS-terminating daemons; the record here does not state a fixed version, so confirm against the advisory. Auditing whether your front end actually swaps SSL_CTX mid-handshake, and whether the two contexts share a library context and provider set, is the fastest way to decide the window is unnecessary. The FIPS module is outside the affected code.

References

Related entries

• Linux kernel (drivers/nvme/target): A client that completes the TLS handshake against the NVMe-oF TCP target and thenCVE-2026-74385 · Linux kernel (drivers/nvme/target)High
• Linux kernel (drivers/nvme/target): Every connection that dies partway through queue allocation on the NVMe-oF TCPCVE-2026-74386 · Linux kernel (drivers/nvme/target)High
• Linux kernel libiscsi: out-of-bounds read leaks stale connection data into the SCSI sense bufferCVE-2026-74557 · Linux kernel libiscsi (SCSI Response sense-data bounds check)High
• Linux kernel LIO iblock: missing PR handler checks let PERSISTENT RESERVE OUT NULL-deref the kernelCVE-2026-80691 · Linux kernel SCSI target (LIO) iblock backend, PERSISTENT RESERVE OUT handlingHigh
• Linux kernel iomap: ioend splitting draws from its own exhausted bio_set and deadlocks writebackCVE-2026-80720 · Linux kernel iomap writeback (iomap_split_ioend sharing iomap_ioend_bioset)High
• Linux kernel crypto/krb5: derived Kerberos keys left in freed slab memoryCVE-2026-80924 · Linux kernel crypto/krb5 (derived key buffers for RPCSEC_GSS)High