Second-pass review of the 54-commit self-correcting audit. Each item below
was confirmed by reading the surrounding source (and, where practical, the
pre-fix code) before being changed; regression tests are included for every
behavioral fix.
Concurrency:
- eventbus: Bus.Subscribe called wg.Add with no synchronization against a
concurrent Bus.Stop's wg.Wait, a real "WaitGroup misuse" panic risk (e.g. a
Telegram-bot settings save racing panel shutdown/restart). Stop now flips a
mu-guarded `stopped` flag before waiting, and Subscribe checks it under the
same lock, so Add and Wait can no longer race.
Security:
- login_limiter: evictForRoom's fallback eviction picked an arbitrary map
key, including ones still under an active cooldown - an attacker flooding
/login with fresh usernames could evict their own (or anyone's) blocked
record and reset the lockout. The fallback now skips actively-blocked
records, only falling back to an unconditional evict if the map is
somehow entirely full of active blocks (preserves the hard memory cap).
Subscription-endpoint panics (reachable by any client hitting /sub):
- internal/sub/service.go: applyPathAndHostParams/Obj (ws/httpupgrade/xhttp
with no path settings object) and the TLS alpn readers in three places
used unchecked type assertions - exactly the bug class abab7cd0 patched
elsewhere in the same switch statements, just not these call sites.
- internal/sub/json_service.go, clash_service.go: the externalProxy loops
in the JSON and Clash generators used unchecked assertions on a
legacy/admin-supplied field (missing "port", non-object entry, etc.).
- internal/sub/json_service.go: realityData's shortId/serverName selection
could assert a non-string array element.
Other correctness:
- client_traffic.go: ResetAllTraffics (touched by 3eb214d0) still skipped
clearing NodeClientTraffic node-sync baselines, unlike its sibling reset
paths in the same file - a node's next sync would re-add pre-reset delta
on top of the freshly-zeroed counter.
- inbound_traffic.go: the traffic-tick tx's Commit/Rollback errors were
silently discarded; now logged so a backend-level commit failure (e.g. an
aborted Postgres tx from a best-effort helper) doesn't masquerade as a
successful tick.
- outbound_subscription.go: the new subscriptionFetchClient doc comment was
wedged between fetchAndStore's existing comment and fetchAndStore itself,
leaving fetchAndStore undocumented and the comment describing the wrong
function.
Convention cleanup:
- Removed narrative // comments added by the audit that violate this repo's
no-inline-comment rule (mostly narrating the specific bug/fix rather than
a lasting contract, and mostly on new Test functions, which this repo's
existing tests never comment) - calibrated against this exact codebase's
own pre-existing comment style so legitimate godoc-style doc comments
were left alone.
AddInbound's per-client validation switch had cases for every protocol
except WireGuard, so a WireGuard client fell through to the default branch
that requires a non-empty id. WireGuard clients are keyed by their public
key and carry no id, so importing a WireGuard inbound or re-adding one to a
reconciling node was rejected with "empty client ID". Add a wireguard case
that validates the client key, mirroring addInboundClient.
The add controller binds the inbound model's id form field and never clears
it, and AddInbound persisted with GORM Save, which updates in place when the
primary key is non-zero. A client that reused an existing id (for instance by
duplicating an inbound fetched from /get and changing the port) silently
overwrote that stored row instead of creating a new inbound. Zero the id at
the top of AddInbound, matching how it already zeroes the client-stat ids.
* fix(inbound): reject finalmask configured together with REALITY security
finalmask wraps the connection before REALITY's own handshake takes
over (TcpmaskManager.WrapListener -> WrapConnServer runs at Accept()
time, ahead of reality.Server()). reality.Server() does an unchecked
type assertion assuming a raw *net.TCPConn; with finalmask in front,
that assertion panics and takes down the entire xray-core process on
the very first connection to the inbound - not just that connection.
Upstream (XTLS/Xray-core#6453) confirmed this will be documented as
unsupported rather than made graceful, so the panel needs to stop this
combination from being saved rather than relying on docs.
AddInbound/UpdateInbound now reject streamSettings with
security=reality and a non-empty finalmask.tcp/udp with a clear error
instead of letting it reach Xray.
Related: MHSanaei/3x-ui#5857
* fix(inbound): heal legacy rows and narrow the finalmask+REALITY guard
Per review feedback on #5861:
- Narrow the check to finalmask.tcp only. xray-core's TcpmaskManager
(the thing that wraps the TCP listener ahead of REALITY's handshake,
the actual cause of the panic) is only constructed when tcp masks
are present; a finalmask.udp-only config never touches that accept
path and doesn't reproduce the crash, so it shouldn't be rejected.
Extracted the shared check into finalMaskRealityTcpMasks() so both
the save-time guard and the config-build heal below use one
definition of "dangerous".
- Heal already-saved bad rows in GetXrayConfig(), the same way
liftXhttpSessionIDKeys and HealShadowsocksClientMethods heal other
legacy data at config-build time. AddInbound/UpdateInbound only cover
the two save paths - a row that already carries this combination
(saved before this guard existed, synced from a node, restored from
a backup, or edited directly in the DB) would still crash Xray-core
on the next restart without this.
- Add end-to-end tests exercising AddInbound, UpdateInbound, and
GetXrayConfig directly (seeding rows through the real DB) rather
than only unit-testing the extracted helper in isolation, so a
wiring regression in any of the three call sites gets caught.
claude[bot]