Server crash in CERT.LV’s Graphoscope when a user disconnects during an upload

§ 01. Overview

Graphoscope is CERT.LV's open-source analysis platform. Analysts query many independent data sources – passive DNS, client databases, leaked-credential sets and others – from one web interface and see the results as a graph of related entities. A user can upload a list of indicators for batch processing; the server works through it in the background and notifies the user over WebSocket when the report is ready.

OffSeq found that this notification could crash the entire server. If the user disconnected before processing finished, the background job wrote to a WebSocket that had already been torn down, and the resulting panic terminated the Graphoscope process.

§ 02. Root cause

uploadHandler starts the processing in a goroutine (upload.go:253). When it finishes, processUploads calls a.send("upload-processed", …) (upload.go:413). Account.send guarded only against a.Session == nil – but when the client disconnects, the deferred teardown in listen() leaves the session in place and clears only the connection:

1defer func() {2    close(a.Session.Done)3    a.Session.Websocket.Close()4    a.Session.Websocket = nil5    delete(online, a.Username)6}()

With a.Session non-nil and a.Session.Websocket nil, the guard passed and WriteMessage dereferenced a nil pointer. The teardown also cleared the field without holding WebsocketMutex, so a nil check in send() alone would still have raced with it. The goroutine had no recover(), so the panic was not contained:

1panic: runtime error: invalid memory address or nil pointer dereference2[signal SIGSEGV: segmentation violation code=0x2 addr=0x10 pc=0x104d606b4]34github.com/gorilla/websocket.(*Conn).WriteMessage(...)5        .../gorilla/websocket@v1.5.3/conn.go:760 +0x246main.(*Account).send(...)7        .../graphoscope/websocket.go:502 +0x1748main.(*Account).processUploads(...)9        .../graphoscope/upload.go:413 +0xaa8

§ 03. Impact

One upload followed by a closed connection takes the whole service down, and every signed-in user loses their session. The crash does not depend on winning a narrow timing window: closing the connection at any point before processing finishes is enough, so the trigger works every time.

Graphoscope allows self-registration through /signup, so the attacker needs nothing beyond an account they create themselves. Repeating the request keeps the platform unavailable for as long as the attacker continues.

§ 04. The fix

OffSeq contributed a fix confined to websocket.go:

• send() returns early when the session is nil, before reading any of its fields – the previous error path dereferenced a.Session.IP in a log line;
• send() re-checks a.Session.Websocket for nil while holding WebsocketMutex, which is where the teardown writes it;
• the teardown in listen() takes the same mutex around Close() and the nil assignment, so a writer never observes a half-closed connection.

On retest the same reproduction left the service running: the log showed the client closing the connection and the processed file being added to the downloads list, and /signin kept answering 200. Three related hardening items were raised as follow-ups – a lock around the shared online map, a top-level recover() in goroutines started from request handlers, and request-context cancellation for in-flight processing. CERT.LV merged the change as pull request #9.