[quic] ngx_quic_input_handler Segmentation fault because c->udp->dgram is null

[Vladimir Homutov]

On Wed, Jan 26, 2022 at 06:38:13AM +0000, Gao,Yan(媒体云) wrote:
> Why sc->type = SOCK_STREAM in ngx_quic_create_stream? Should it be SOCK_DGRAM?

no, SOCK_STREAM is a correct setting for the quic streams.
SOCK_DGRAM is only used for main quic connection which actually handles
UDP datagrams and deals with QUIC protocol. Streams is an abstract layer
that utilizes ngx_connection_t with custom event handling.

> I guess the problem function call chain: final_early_data(openssl)->
> quic_set_encryption_secrets-> ngx_quic_set_encryption_secrets ->
> ngx_quic_init_streams -> ngx_ssl_ocsp_validate-> ngx_handle_read_event

> But this connection->quic would always be null, and cannot jump to
> quic if branch in ngx_handle_read_event

the case you are describing is not what see in backtrace. And in
described case connection is main quic connection which has process
c->quic pointer set.

> >  Thank you for report!
> >  Can you please enable debug and provide debug log?
>
> Sorry, this is a very rare case, and do not know how to trigger this bug steadily
> here is more data from the stack

ok, what exactly code revision are you running ? Line numbers (if
correct) guess that it's something quite different from the current.

normally, you only see c->udp->dgram = NULL only in packets that were
not dispatched by dcid to any existing connection, and the handler is
ngx_quic_run().

If packet goes to known connection, c->udp->dgram is initialized and the
handler is ngx_quic_input_handler().

Hope this helps.

> p *c
> $1 = {data = 0x7efd695c74c0, read = 0xf2aa990, write = 0xfa72ca0, fd = 5547, recv = 0x4a7c9a <ngx_udp_shared_recv>, send = 0x4ab5b9 <ngx_udp_unix_send>, recv_chain = 0x0,
>   send_chain = 0x4ab7a7 <ngx_udp_unix_sendmsg_chain>, listening = 0x29cf140, sent = 0, log = 0x7efd695c73f0, pool = 0x7efd695c7330, type = 2, sockaddr = 0x7efd695c7380, socklen = 16,
>   addr_text = {len = 15, data = 0x7efd695c74b0 "123.101.125.168.H\270(\v"}, proxy_protocol = 0x0, quic = 0x0, ssl = 0x1e491e8, udp = 0x1e49150, local_sockaddr = 0x7efd695c7440, local_socklen = 16,
>   buffer = 0x7efd695c7450, queue = {prev = 0x0, next = 0x0}, number = 433923428, start_time = 3194843312, requests = 0, buffered = 0, log_error = 2, timedout = 0, error = 0,
>   destroyed = 0, idle = 0, reusable = 0, close = 0, shared = 1, sendfile = 0, sndlowat = 0, tcp_nodelay = 0, tcp_nopush = 0, need_last_buf = 0}
>
> p *c->ssl
> $2 = {connection = 0x7efd708fdb00, session_ctx = 0x7efd69052970, last = 0, buf = 0x0, buffer_size = 16384,
>   handler = 0x0, session = 0x0, save_session = 0x0, saved_read_handler = 0x0, saved_write_handler = 0x0, ocsp = 0x0, early_buf = 0 '\000', handshaked = 0, handshake_rejected = 0, renegotiation = 0,
>   buffer = 1, sendfile = 0, no_wait_shutdown = 1, no_send_shutdown = 0, shutdown_without_free = 0, handshake_buffer_set = 0, try_early_data = 0, in_early = 0, in_ocsp = 0, early_preread = 0, write_blocked = 0}
>
> And you can see it happened before handshaked
>
> Gao,Yan(ACG VCP)

> _______________________________________________
> nginx-devel mailing list -- nginx-devel at nginx.org
> To unsubscribe send an email to nginx-devel-leave at nginx.org