Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

5.3.0 regression: SSL_set_cert_cb(..., NULL, ...) stores a null function pointer instead of clearing, crashing the next handshake

Abierto
  • ¿Algo no está bien?
#537 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@dorianverlaine ya está trabajando en esto.

Desde el 15/10/2026.

  • #538 de @dorianverlaine — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cpp, rust
Área
security

Línea de trabajo

Start in ssl/ssl_cert.cc at ssl_cert_set_cert_cb (both overloads), where a null callback is stored as an OldCallback instead of resetting to std::monostate, and check CertCb::operator bool() in ssl/internal.h. Then trace do_cert_callback in ssl/handshake_server.cc. A regression test should call SSL_set_cert_cb(ssl, NULL, NULL) and complete a server handshake without invoking a callback. Done when clearing with NULL leaves the callback absent and that test passes, with any boring-sys/patches/ entry kept consistent with the upstream fix.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

In boring / boring-sys 5.3.0 (BoringSSL revision 427ec40c), clearing a certificate callback by passing NULL no longer resets it to the empty state. The null pointer is stored as an OldCallback alternative inside CertCb::cb, so CertCb::operator bool() reports the callback as present, and do_cert_callback then invokes a null function pointer. On our machines this crashes the server process during the resumed TLS handshake and currently keeps us from upgrading to 5.3.0.

Root cause

Introduced by google/boringssl commit 902518a787 ("ssl: Allow certificate selection callback to pick fatal alert"), which turned CERT::cert_cb into struct CertCb { std::variant<std::monostate, OldCallback, NewCallback> }:

 // ssl/ssl_cert.cc, ssl_cert_set_cert_cb (both overloads)
-  cert->cert_cb = cb;
+  cert->cert_cb.cb = cb;

Assigning a null function pointer selects the OldCallback alternative by exact type match rather than monostate, so the "cleared" representation is no longer reachable through this setter. CertCb::operator bool() (ssl/internal.h) only excludes monostate, and do_cert_callback (ssl/handshake_server.cc) calls the callback whenever that conversion is true.

Reproduction (real world)

Pingora's resumable TLS accept uses exactly this pattern: it arms a blocking cert_cb (suspend_when_need_ssl_cert), pauses the handshake, installs the certificate, then clears the callback with SSL_set_cert_cb(ssl, NULL, NULL) before resuming (unblock_ssl_cert in pingora-boringssl). With 5.3.0 every resumed handshake crashes:

bssl::CertCb::operator()(ssl_st*, void*, unsigned char*) const
bssl::do_cert_callback(bssl::SSL_HANDSHAKE*)
bssl::ssl_server_handshake(bssl::SSL_HANDSHAKE*)
...
SSL_do_handshake
SSL_accept

(excerpt from the macOS crash report: EXC_BAD_ACCESS, invalid address 0x0)

Bisecting boring/boring-sys back to 5.2.0 makes all of this disappear: 33 failing integration tests go back to green. SSL_CTX_set_cert_cb(ctx, NULL, arg) alone should be enough to hit the same path on the next server handshake.

Suggested fix

Normalize a null callback to the empty state in ssl_cert_set_cert_cb, restoring the previous "NULL clears" behavior:

if (cb == nullptr) {
  cert->cert_cb.cb = std::monostate();
} else {
  cert->cert_cb.cb = cb;
}

(same for the _ex overload.)

Notes

  • The same code is present on google/boringssl main as of 2026-10-15.
  • Reproduced on macOS 27.0.1 (26A434) aarch64, rustc 1.99.0; the defect in the C++ itself is platform-independent.
  • Happy to send a PR that carries the change as a boring-sys/patches/ entry with a regression test, if that is the preferred route — or to help get it into BoringSSL if you would rather pick it up with the next revision bump.
Lenguaje dominante
Rust
Estrellas
526
Forks
178
Merge medio
15 h 34 min
PR fusionados (30 d)
9

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudflare/boring

Todos los issues de cloudflare/boring

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.