Possible null dereference in WebSocket handling

[dqp10515]

While doing some robustness testing of Mosquitto’s use of the libwebsockets API, the integration generally performs very well. I did notice a single potential issue related to wsi->protocol being NULL.

The crash trace looks like this:

websockets.c:143:25: runtime error: member access within null pointer of type 'const struct lws_protocols'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior websockets.c:143:25 in 
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2282291==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x000000779c3a bp 0x7ffdb2b4f4b0 sp 0x7ffdb2b4d1a0 T0)
==2282291==The signal is caused by a READ memory access.
==2282291==Hint: address points to the zero page.
    #0 0x779c3a in callback_mqtt mosquitto/src/websockets.c:143:25
    #1 0x7f572855d516 in lws_server_init_wsi_for_ws libwebsockets/lib/roles/ws/ops-ws.c:798:7
    #2 0x7f5728576a6b in lws_process_ws_upgrade libwebsockets/lib/roles/ws/server-ws.c:457:2
    #3 0x7f572861c01e in lws_handshake_server libwebsockets/lib/roles/http/server/server.c:1933:7
    #4 0x7f572854a647 in lws_read_h1 libwebsockets/lib/roles/h1/ops-h1.c:75:7
    #5 0x7f572854c726 in lws_h1_server_socket_service libwebsockets/lib/roles/h1/ops-h1.c:404:8
    #6 0x7f572854c726 in rops_handle_POLLIN_h1 libwebsockets/lib/roles/h1/ops-h1.c:611:7
    #7 0x7f57285217af in lws_service_fd_tsi libwebsockets/lib/core/service.c:1024:10
    #8 0x7f57286056e4 in _lws_plat_service_tsi libwebsockets/lib/plat/unix/unix-service.c:168:7
    #9 0x7f5728527938 in lws_service libwebsockets/lib/core/service.c:1094:6
    #10 0x5ddb22 in mosquitto_main_loop mosquitto/src/loop.c:266:5
    #11 0x4cf501 in main mosquitto/src/mosquitto.c:592:7
    #12 0x7f57281b40b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #13 0x41fead in _start (mosquitto/src/mosquitto+0x41fead)


SUMMARY: AddressSanitizer: SEGV mosquitto/src/websockets.c:143:25 in callback_mqtt
==2282291==ABORTING

lws_get_protocol(wsi) may temporarily return NULL when the WebSocket connection is in an early or teardown state, such as before protocol binding completes or after it has been unbound. It can also occur for listener or placeholder WSIs.

Just sharing this for reference — hope it’s helpful!

[ralight]

Thank you. Is this a real or theoretical bug? From the brief look I've had so far, I haven't seen how callback_mqtt can be called before the client knows what protocol it is using.