A bug introduced in rustls 0.23.13 leads to a panic if the receivedTLS ClientHello is fragmented. Only servers that userustls::server::Acceptor::accept() are affected.

Servers that usetokio-rustls'sLazyConfigAcceptor API are affected.

Servers that usetokio-rustls'sTlsAcceptor API are not affected.

Servers that userustls-ffi'srustls_acceptor_accept API are affected.

Inopenssl versions before0.10.70,ssl::select_next_proto can return a slice pointing into theserver argument's buffer but with a lifetime bound to theclient argument. In situations where theserver buffer's lifetime is shorter than theclient buffer's, this can cause a use after free. This could cause the server to crash or to return arbitrary memory contents to the client.

openssl 0.10.70 fixes the signature ofssl::select_next_proto to properly constrain the output buffer's lifetime to that of both input buffers.

In standard usage ofssl::select_next_proto in the callback passed toSslContextBuilder::set_alpn_select_callback, code is only affected if theserver buffer is constructedwithin the callback. For example:

Not vulnerable - the server buffer has a'static lifetime:

builder.set_alpn_select_callback(|_, client_protos| {    ssl::select_next_proto(b"\x02h2", client_protos).ok_or_else(AlpnError::NOACK)});

Not vulnerable - the server buffer outlives the handshake:

let server_protos = b"\x02h2".to_vec();builder.set_alpn_select_callback(|_, client_protos| {    ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK)});

Vulnerable - the server buffer is freed when the callback returns:

builder.set_alpn_select_callback(|_, client_protos| {    let server_protos = b"\x02h2".to_vec();    ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK)});