Fix data race in SessionCommon Close() and Ping() methods

Protect concurrent access to sm.yamux and sm.smux fields with sm.mutx lock to prevent data races when Close() or Ping() are called while session is being initialized.

The race occurred when:
- handleSession() writes to dSes.sm.yamux (server.go:242) while holding the lock
- Close() reads sc.sm.yamux (session_common.go:187-188) without holding the lock
- A goroutine can call Close() concurrently during session setup

Changes:
- Add sm.mutx.Lock() protection in Close() method
- Add sm.mutx.RLock() protection in Ping() method for consistency

💘 Generated with Crush
Co-Authored-By: Crush <[email protected]>

Author: 0pcom

pkg/dmsg/session_common.go

@@ -169,6 +169,8 @@ func (sc *SessionCommon) RemoteTCPAddr() net.Addr { return sc.netConn.RemoteAddr
 
 // Ping obtains the round trip latency of the session.
 func (sc *SessionCommon) Ping() (time.Duration, error) {
+	sc.sm.mutx.RLock()
+	defer sc.sm.mutx.RUnlock()
 	if sc.sm.yamux != nil {
 		return sc.sm.yamux.Ping()
 	}
@@ -181,12 +183,14 @@ func (sc *SessionCommon) Close() error {
 		return nil
 	}
 	var err error
+	sc.sm.mutx.Lock()
 	if sc.sm.smux != nil {
 		err = sc.sm.smux.Close()
 	}
 	if sc.sm.yamux != nil {
 		err = sc.sm.yamux.Close()
 	}
+	sc.sm.mutx.Unlock()
 	sc.rMx.Lock()
 	sc.nMap = nil
 	sc.rMx.Unlock()