[bug]: chan_websocket: long connection URI (uri + v() params) overflows the stack (SIGBUS)

Asterisk Asterisk APIs
1

[bug]: chan_websocket: long connection URI (uri + v() params) overflows the stack (SIGBUS)

Version: 22.8.2 (aarch64, Debian 12)

Modules: chan_websocket, res_websocket_client, res_http_websocket

Summary

For an outbound chan_websocket connection, the v() dial variables are appended as a query string to the uri in websocket_client.conf. When the assembled URI is long (~300 bytes), Asterisk crashes with SIGBUS during connect. The core shows the saved return address overwritten with the ASCII bytes of the URI, i.e. a stack buffer overflow whose payload is the connection URI. The appended values come from per-call data, so call traffic can crash the process.

Reproduce

  1. websocket_client.conf: a type=websocket_client connection with a normal uri.

  2. Dial it with enough/long v() params that the assembled URI exceeds ~300 bytes:

Dial(WebSocket/c1/c(ulaw)v(a=${URIENCODE(${V1})},b=${URIENCODE(${V2})},c=${URIENCODE(${V3})},d=${URIENCODE(${CHANNEL})}),300)

  1. Place calls. Long-URI calls crash with SIGBUS on connect.

Evidence (unstripped 22.8.2 core)


signal SIGBUS

x30 (saved return address) = ASCII bytes of the URI query value

Assembled URI was 301 bytes; the saved return address sat 280 bytes into the URI buffer, so the URI overran it.

Chain: Dial(WebSocket) -> ast_call -> webchan_call -> ast_websocket_client_connect -> websocket_client_handshake_get_response.

The assembly site (ast_websocket_client_connect, exact-size ast_alloca + bounded sprintf) is safe, so the unbounded write is downstream on the connect/handshake path.

Expected

Long URI handled safely (bounded/dynamic) or rejected with an error. Never corrupt the stack.

Full core + unstripped binary available on request.

2

The forum is not our issue tracker. Issues are filed on Github at Issues · asterisk/asterisk · GitHub

3

Thanks jcolp, raised it on Github