A single unauthenticated packet crashes TDengine's taosd through an integer underflow

The crash lives in pre-authentication connection processing, so credentials never enter into it ^[2]. When taosd reads an incoming RPC message, it subtracts two quantities from the declared message length: the size of STransMsgHead and the offset for the required user information ^[3]. Send a message whose declared length is smaller than that sum, and the subtraction produces a negative number held in an unsigned type, which wraps to a very large positive value ^[3]. That value is handed to memcpy as a length ^[3]. memcpy then reads past the allocated heap buffer, and taosd terminates with a segmentation fault ^[4]. The crafted header reaches this calculation in the function uvConnMayGetUserInfo() ^[5].

Detecting the attempt is not a job for the usual logs. A web proxy, secure web gateway, or DNS record cannot see inside a TCP/6030 RPC request ^[9]. Ridge Security's guidance is to capture traffic on the port, read msgLen out of the packets, and line up suspicious requests with taosd crash timestamps ^[10]. On the host, the clues are taosd segmentation faults, core dumps, and restarts initiated by systemd ^[11]. Because successful authentication is never part of the path, the absence of login events rules nothing out ^[12].

What a crash costs depends on timing. Abnormal termination can lose uncommitted writes, stop data collection, and halt alerts, but according to Ridge Security it does not lose durably committed data or run attacker code ^[16][17]. Ridge Security verified in a research environment that crafted packets stop taosd, and says remote code execution and real-world exploitation have not been confirmed ^[18][19]. A suspicious RPC request on its own is not a confirmed denial of service; it has to match a taosd termination and a service outage at the connection timestamp before it counts ^[20].