Skip to content

Fix unsynchronized map write in plugin Manager.RemoveUser#1005

Open
Osamaali313 wants to merge 1 commit into
gotify:masterfrom
Osamaali313:fix/plugin-instances-map-race
Open

Fix unsynchronized map write in plugin Manager.RemoveUser#1005
Osamaali313 wants to merge 1 commit into
gotify:masterfrom
Osamaali313:fix/plugin-instances-map-race

Conversation

@Osamaali313

Copy link
Copy Markdown

Problem

Manager.RemoveUser (plugin/manager.go) deletes from the m.instances map without holding m.mutex:

if pluginConf.Enabled {
    inst, err := m.Instance(pluginConf.ID)
    ...
    m.mutex.Lock()
    err = inst.Disable()
    m.mutex.Unlock()
    ...
}
delete(m.instances, pluginConf.ID)   // <-- unguarded map write

Every other access to m.instances is synchronized:

  • Instance() reads it under m.mutex.RLock().
  • The writes in InitializeForUserID / initializeSingleUserPlugin happen under m.mutex.Lock().

The author even wraps the adjacent inst.Disable() in Lock/Unlock — only this map delete is left unguarded.

Impact

RemoveUser is registered as the OnUserDeleted callback (router.go: userChangeNotifier.OnUserDeleted(pluginManager.RemoveUser)), fired when an admin deletes a user (DELETE /user/:id). Concurrently, any authenticated request to the plugin API (GET /plugin, GET/POST /plugin/:id/*) reads m.instances via Instance() under RLock. An RLock reader is not protected against a writer that never takes the mutex, so an admin deleting a user (who has plugin configs) while a client polls plugins races the map.

That triggers Go's runtime-fatal concurrent map read and map write — a fatal error that gin.Recovery() cannot recover, crashing the whole server process and dropping all WebSocket streams and in-flight requests.

Reproduction

A minimal program mirroring the exact pattern (an RLock-guarded read in one goroutine vs. an unguarded delete in another) reliably fatals:

fatal error: concurrent map read and map write

Fix

Take the write lock around the delete, matching every other m.instances access:

m.mutex.Lock()
delete(m.instances, pluginConf.ID)
m.mutex.Unlock()

`Manager.RemoveUser` deletes from `m.instances` without holding `m.mutex`:

    delete(m.instances, pluginConf.ID)

Every other access to `m.instances` is synchronized — `Instance` reads it
under `m.mutex.RLock()`, and the writes in `InitializeForUserID` /
`initializeSingleUserPlugin` happen under `m.mutex.Lock()`. The adjacent
`inst.Disable()` call in this same loop is even wrapped in Lock/Unlock, so
only the map delete is left unguarded.

`RemoveUser` is registered as the `OnUserDeleted` callback (router.go), fired
when an admin deletes a user, while any authenticated request to the plugin
API (`GET /plugin`, `/plugin/:id/*`) concurrently reads `m.instances` via
`Instance`. A `RLock` reader is not protected against a writer that never
takes the mutex, so this races and triggers Go's runtime-fatal
"concurrent map read and map write", crashing the whole server (a fatal that
gin.Recovery cannot recover). Take the write lock around the delete, matching
every other access.
@Osamaali313
Osamaali313 requested a review from a team as a code owner July 18, 2026 20:35
Copilot AI review requested due to automatic review settings July 18, 2026 20:35

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@codecov

codecov Bot commented Jul 19, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.56%. Comparing base (497f945) to head (883ca85).

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1005      +/-   ##
==========================================
+ Coverage   74.54%   74.56%   +0.01%     
==========================================
  Files          66       66              
  Lines        3485     3487       +2     
==========================================
+ Hits         2598     2600       +2     
  Misses        688      688              
  Partials      199      199              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants