github.com/bytedance/gopkg Go module: is it safe?

In entry.Store, when x == nil, e.val = atomic.Value{} replaces the whole atomic.Value, which can race with concurrent readers calling e.val.Load() and cause inconsistent reads or panics. Also, err is stored unconditionally, and in refresh() the condition if e.err.Load() != nil { e.err.Store(err) } means a new error overwrites an old error only when an old error already exists — confusing semantics likely to cause stale/missed error state.

In DeleteIf, expire, refresh and tick methods, user-supplied handlers (DeleteHandler, ErrorHandler, ChangeHandler) are invoked inside go routines without any bound, pool, or backpressure. A high-churn cache could spawn an unbounded number of goroutines, exhausting resources. Also, Dump() and Refresh iterate with c.data.Range while calling handlers concurrently in goroutines that may delete entries.

In Close(), rt := ti.(*sharedTicker) will panic if refreshTickerMap.Load returns nil (e.g., if Close is called on a cache whose ticker entry was removed). Similar unchecked type assertions in tick() and expire() can panic on malformed/unexpected values inside the sync.Map, potentially crashing the host application.

The Close() method sends to stopChan (buffered size 1) and sets started=false, but if Close is called multiple times or in race conditions, the channel send could block or panic if a ticker goroutine is not running or the buffered slot already contains a value (e.g., two caches sharing the same ticker duration closed in quick succession before the tick arrives could deadlock or block one of them).

The file declares several functions without Go bodies (compareAndSwapUint128, loadUint128, loadSCQNodePointer, etc.), which are implemented in hand-written assembly. Hand-written assembly is opaque to static analysis and could contain hidden malicious logic such as data exfiltration or backdoors. In this case, the file is part of ByteDance's lscq library (a known lock-free queue), but the assembly implementations in companion files should be audited.

The code uses //go:linkname to access internal runtime functions (runtime.atomicwb, runtime.noescape) and unsafe.Pointer manipulations. While this is a legitimate optimization technique for lock-free data structures, it is a fragile and powerful mechanism that bypasses Go's type safety and could be abused or break in unexpected ways. It does not appear malicious in this context, but warrants review.

The file uses unsafe pointers and //go:linkname directives to access internal runtime functions (runtime.atomicwb, runtime.noescape) and internal/cpu.sysctlEnabled. While these are used here for a legitimate lock-free queue implementation, this pattern bypasses Go's type safety and internal API stability guarantees. Misuse could lead to memory corruption or undefined behavior. This is a medium-severity concern because it relies on non-public runtime internals that could change between Go versions.

The file uses //go:linkname to access an unexported runtime function (runtime.cmpstring). This bypasses Go's type safety and encapsulation, and may break in future Go versions. While not inherently malicious, it is a fragile and non-idiomatic pattern that could be exploited if the runtime function signature changes or is altered by an attacker.

The package uses unsafe.Pointer and reflect.SliceHeader/StringHeader to perform zero-copy conversions between strings and byte slices. The StringToBytes function (line 28-35) creates a byte slice that shares memory with an immutable string, and the documentation explicitly warns the caller must not modify the returned slice. If any caller violates this contract, it results in undefined behavior, memory corruption, or potential security vulnerabilities. Similarly, BytesToString (line 41-43) returns a string that shares the underlying byte slice, meaning later mutations of the original byte slice (or garbage collection if the slice isn't kept alive) can cause data corruption or unexpected behavior. Though these are common 'hack' patterns used by high-performance libraries (e.g., fasthttp, bytedance/sonic for performance), they bypass Go's memory safety guarantees.

The code uses //go:linkname to access internal runtime functions (runtime.procPin and runtime.procUnpin). This bypasses Go's type safety and encapsulation by directly linking to unexported runtime symbols. While used here for legitimate performance optimization (pinning goroutines to OS threads), this technique is fragile, relies on undocumented runtime internals, and could break across Go versions. It is not inherently malicious but represents an unsafe pattern that warrants caution.

The code uses //go:linkname to access the unexported standard library function runtime.cheaprand. This bypasses Go's type safety and encapsulation guarantees, and relying on internal runtime symbols is fragile and non-portable across Go versions. While this is a common technique for performance optimization (e.g., to expose fastrand), it is a known unsafe pattern that can be abused to access internal runtime state.

The //go:linkname directive links to runtime.mallocgc, an internal runtime function. This technique is fragile, unsupported, and could break across Go versions. In a malicious context, linkname can also be abused to access or modify internal runtime state. Here it is used only for allocation, but it increases the attack surface and reduces auditability.

The code uses //go:linkname to access the runtime private function mallocgc and unsafe.Pointer to construct a byte slice without zeroing the allocated memory. This bypasses Go's memory safety guarantees and can expose uninitialized memory contents if the caller reads the buffer before fully writing to it. While intended for performance in trusted code, this pattern is risky in a third-party package because it may leak sensitive data from previously freed memory or cause undefined behavior.

The Read function uses unsafe.Pointer to reinterpret a []byte slice as a []uint64 slice, bypassing Go's type safety. This can lead to memory corruption, misaligned access, or panic on platforms with strict alignment requirements (e.g., ARM) when the byte slice is not 8-byte aligned. Although not malicious, it is a dangerous pattern.

Uses unsafe.Pointer to manipulate slice headers (bytesHeader struct) to directly set Data, Len, and Cap fields. This bypasses Go's memory safety guarantees and could lead to memory corruption if misused, though in this case it appears to be an intentional high-performance memory pool implementation.

Uses dirtmake.Bytes from github.com/bytedance/gopkg/lang/dirtmake for memory allocation. This bypasses Go's standard allocation mechanisms. The 'dirtmake' package name suggests it creates uninitialized (dirty) memory, which could potentially expose stale data from previously freed memory if not properly zeroed, though the Free function returns buffers to the pool for reuse.

The file uses //go:linkname directives to bind to unexported internal symbols in the Go standard library's sync package: sync.runtime_registerPoolCleanup and sync.poolCleanup. This technique bypasses Go's type and encapsulation safety mechanisms and relies on undocumented internals that can break across Go versions. While used in legitimate projects (e.g., bytedance/sonic) for performance workarounds, linkname to runtime internals is a recognized red flag because it enables tampering with runtime behavior and is fragile/malicious-adjacent if used to hook or manipulate GC/cleanup behavior.

runtime_registerPoolCleanup accepts and registers an arbitrary function pointer with the runtime's sync.Pool cleanup mechanism, and runtime_poolCleanup can force a global pool cleanup. This grants the package the ability to influence runtime-wide memory/cleanup behavior outside its own scope, which is not typical for a normal library and could be abused to interfere with other packages' pooled objects.

This file uses go:linkname to hook into Go's internal runtime pool cleanup mechanism (runtime_registerPoolCleanup). The comment explicitly warns 'The linkname here is risky.' While this appears to be a legitimate performance optimization (similar to sync.Pool internals), linkname usage violates Go's compatibility contract and can break with runtime changes. It grants access to unexported runtime internals, which is a privilege that could be abused.