# github.com/bytedance/gopkg@v0.1.3 security report (Go)

- Verdict: **Needs review** (risk level: medium)
- Scanned: 2026-10-05T19:10:27.000Z
- Files reviewed: 85
- Findings: 19 medium, 19 low severity findings
- Report: https://security.togoder.click/go/github.com/bytedance/gopkg
- Source: Togoder Security (https://security.togoder.click), AI source-code review

## Summary

Togoder Security scanned the Go package github.com/bytedance/gopkg@v0.1.3 on Oct 5, 2026. An AI review of 85 source files produced 19 medium, 19 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.

## Findings

### [medium] Logic bug / stale error propagation

Finding ID: `NPS-32B74B3B84BF`

File: `cache/asynccache/asynccache.go:90`

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.

### [medium] Unbounded goroutine spawning / denial of service

Finding ID: `NPS-16D8F7D588F4`

File: `cache/asynccache/asynccache.go:155`

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.

### [medium] Panic on type assertion / nil map access

Finding ID: `NPS-8F0724F8EA76`

File: `cache/asynccache/asynccache.go:205`

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.

### [medium] Resource leak / goroutine management

Finding ID: `NPS-35A4BF254B48`

File: `cache/asynccache/asynccache.go:210`

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).

### [medium] assembly/foreign function interface

Finding ID: `NPS-3DC08D4F6034`

File: `collection/lscq/asm.go:24`

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.

### [medium] unsafe compiler directives / runtime internals access

Finding ID: `NPS-7F71C78A9215`

File: `collection/lscq/asm.go:47`

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.

### [medium] Use of unsafe and go:linkname to access runtime internals

Finding ID: `NPS-414C63FC5995`

File: `collection/lscq/asm_arm64.go:1`

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.

### [medium] unsafe linkname directive

Finding ID: `NPS-22AF1F9B7896`

File: `collection/skipset/util.go:28`

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.

### [medium] Unsafe memory operations / potential security vulnerability

Finding ID: `NPS-46B7FCADFB5B`

File: `internal/hack/hack.go:28`

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.

### [medium] Use of unsafe go:linkname directive

Finding ID: `NPS-BF6F94871489`

File: `internal/runtimex/ppin.go:21`

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.

### [medium] unsafe linkname usage

Finding ID: `NPS-476D078ABB49`

File: `internal/runtimex/runtime_go_1.22.go:19`

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.

### [medium] Linkname directive bypassing API boundaries

Finding ID: `NPS-35694256CA54`

File: `lang/dirtmake/bytes.go:26`

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.

### [medium] Unsafe memory manipulation

Finding ID: `NPS-50C64DD5405E`

File: `lang/dirtmake/bytes.go:31`

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.

### [medium] Unsafe memory manipulation

Finding ID: `NPS-1F87546DFF2B`

File: `lang/fastrand/fastrand.go:184`

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.

### [medium] unsafe pointer usage

Finding ID: `NPS-8230245E7919`

File: `lang/mcache/mcache.go:33`

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.

### [medium] custom memory allocation

Finding ID: `NPS-6C97A4DDC6DE`

File: `lang/mcache/mcache.go:36`

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.

### [medium] Unsafe linkage to internal runtime symbols

Finding ID: `NPS-E3D6BD4C3EB9`

File: `lang/syncx/linkname.go:22`

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.

### [medium] Runtime introspection/hooking capability

Finding ID: `NPS-DD1F06922899`

File: `lang/syncx/linkname.go:23`

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.

### [medium] runtime linkname manipulation

Finding ID: `NPS-73712B971687`

File: `lang/syncx/pool.go:265`

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.

### [low] Potential unbounded / uncontrolled execution at import / package init

Finding ID: `NPS-EBB4BC7527E0`

File: `cache/asynccache/asynccache.go:78`

Package-level `var` declarations (refreshTickerMap, expireTickerMap) are shared mutable global state. NewAsyncCache starts background ticker goroutines immediately. If this package is imported and NewAsyncCache is called with attacker-influenced RefreshDuration/ExpireDuration or Fetcher key values, it can trigger repeated network/file operations on a schedule. No direct external calls are made here, but the shared ticker design means any consumer of the package controls the schedule.

### [low] Suspicious use of singleflight with external key

Finding ID: `NPS-13CE8F9DAA71`

File: `cache/asynccache/asynccache.go:145`

Get uses `c.sfg.Do(key, ...)` with the caller-supplied cache key as the singleflight key. Keys are not validated or namespaced. Combined with GetOrSet semantics, this could allow a caller to store attacker-controlled values into the cache under any key. Not malicious itself, but worth noting as an injection vector for downstream consumers.

### [low] Code generation tool

Finding ID: `NPS-DB2C75B6E1F8`

File: `collection/hashset/types_gen.go`

This file is a build-tagged code generator (build ignore) that reads hashset.go, generates type-specific variants, and writes types.go. It uses only os, io/ioutil, strings, bytes, and go/format. There is no network access, no environment/credential harvesting, no obfuscation, no dynamic execution beyond go/format parsing generated source, and no process spawning. File operations are limited to package-local files.

### [low] unsafe pointer operations

Finding ID: `NPS-2723138EE341`

File: `collection/lscq/asm.go:38`

Extensive use of unsafe.Pointer and type conversion could lead to memory corruption if misused. The //go:nosplit directive suppresses stack-growth checks, which is typical for low-level synchronization primitives but increases risk of subtle memory bugs.

### [low] Low-level assembly and unsafe memory manipulation

Finding ID: `NPS-AA50081DAF30`

File: `collection/lscq/asm_arm64.go:1`

The code declares external assembly functions (compareAndSwapUint128, loadUint128, etc.) and uses unsafe.Pointer with uint128 casts. This is typical for high-performance synchronization primitives but represents a potential risk if the assembly implementations contain bugs or if the package is compromised (assembly is harder to audit). No immediate malicious pattern is evident, but it warrants scrutiny.

### [low] Init-time detection without network or filesystem access

Finding ID: `NPS-CC5329711DC1`

File: `collection/lscq/asm_arm64.go:34`

The package-level variable arm64HasAtomics = detectArm64HasAtomics() executes at import time. It only queries CPU features via sysctl or cpu.ARM64.HasATOMICS and does not perform any network, filesystem, or process operations. This is considered safe behavior.

### [low] Code Generation Script

Finding ID: `NPS-D13512E4F74D`

File: `collection/skipmap/types_gen.go`

The file is a Go code generator (build-ignored via //go:build ignore) that reads skipmap.go and produces types.go. It performs string replacements to generate type-specialized implementations for various numeric and string types. It contains no network operations, credential harvesting, obfuscated payloads, dynamic code execution, process spawning, or other malicious patterns. File operations are limited to reading source template and writing generated output within the package scope.

### [low] Dependency on internal package with native/assembly hashing

Finding ID: `NPS-3B5B64C19892`

File: `collection/skipmap/util.go:30`

The code depends on `github.com/bytedance/gopkg/internal/wyhash` for hashing. The `internal` path restriction only applies within the module; if this package is copied/extracted or the module boundary is bypassed, behavior may differ. The hashing implementation itself is not shown here, so its correctness and constant-time properties cannot be verified from this file alone. Non-cryptographic use here (skipmap key hashing) is not inherently malicious, but it is worth noting for integrity verification.

### [low] Use of unsafe/linkname to access unexported runtime internals

Finding ID: `NPS-FEFA63D4CAB4`

File: `collection/skipmap/util.go:35`

The file imports `unsafe` blank and uses `//go:linkname cmpstring runtime.cmpstring` to bind to an unexported internal runtime function. While this is a known optimization technique used in performance-sensitive Go code, linkname-based access to runtime internals is fragile, unsupported, and can be leveraged to bypass encapsulation or hook behavior in ways that are not visible to normal source inspection.

### [low] internal package import

Finding ID: `NPS-705C60E9FEEF`

File: `collection/skipset/util.go:23`

Imports github.com/bytedance/gopkg/internal/wyhash. Internal packages are restricted by Go's package visibility rules; only code within the same module can import them. This suggests the file is part of the module itself, but if this code were copied to a third-party package, the import would fail. No malicious behavior is evident, but the dependency on an internal implementation is a maintenance risk.

### [low] Runtime manipulation

Finding ID: `NPS-4C503547DA2E`

File: `internal/runtimex/ppin.go:30`

Pin and Unpin directly manipulate Go's scheduler runtime state by pinning the current goroutine to a processor (P). If misused (e.g., failing to unpin), this can cause scheduler starvation or deadlocks. The API also explicitly warns 'DO NOT USE if you don't know what this is.'

### [low] Import of unsafe package

Finding ID: `NPS-425F2BAFB6D0`

File: `internal/runtimex/runtime_pre_go_1.22.go:20`

The file imports the unsafe package (blank import) solely to enable linkname. Importing unsafe expands the attack surface and is a common prerequisite for memory-corruption or runtime-hooking payloads, though in this file it is only used as a directive enabler.

### [low] Unsafe compiler directive

Finding ID: `NPS-EDC20E3ACA44`

File: `internal/runtimex/runtime_pre_go_1.22.go:24`

Uses //go:linkname to access runtime.fastrand, an unexported internal Go runtime function. While used here for legitimate performance reasons (matching upstream ByteDance/sonic), linkname directives bypass Go's type and visibility safety guarantees and can break across Go versions. Linkname is a known technique abused in supply-chain compromises (e.g., the tj-actions/changed-files and 'rsc' style attacks) to reach into runtime internals, so this pattern warrants scrutiny.

### [low] init function execution

Finding ID: `NPS-D488B1F8F438`

File: `lang/mcache/mcache.go:31`

Contains an init() function that runs at package import time, initializing sync.Pool instances with a custom New function. While this is legitimate initialization for a memory cache, init() functions execute automatically upon import and should be reviewed for side effects.

### [low] init-time runtime registration

Finding ID: `NPS-DB36D3C14F2E`

File: `lang/syncx/pool.go:262`

An init() function registers a GC callback directly into the Go runtime's stop-the-world gc cycle. This executes at import time and hooks into a critical runtime path. A malicious actor could abuse this hook to inject code that runs during every GC (e.g., data exfiltration or state manipulation), though no such behavior is present here.

### [low] unsafe pointer arithmetic

Finding ID: `NPS-E6A987EBE078`

File: `lang/syncx/pool.go:268`

Extensive use of unsafe.Pointer with atomic operations and manual pointer arithmetic (indexLocal) to implement a custom sync.Pool variant. This is a low-level, potentially memory-unsafe implementation pattern. It is used here for legitimate performance reasons (mimicking sync.Pool), but this complexity could hide memory corruption or misuse if modified maliciously.

### [low] unsafe pointer arithmetic

Finding ID: `NPS-CBEF426483D1`

File: `util/xxhash3/accum_scalar.go`

The code uses the unsafe package and unsafe.Pointer with manual offset arithmetic to read unaligned 64-bit integers from input data. While this is a common performance optimization in hash implementations, incorrect offset calculations could lead to out-of-bounds reads. However, the loop bounds appear carefully controlled (l-1)/1024 and (l-1)/_stripe, and the final stripe explicitly adjusts backwards to remain in bounds. This is a correctness/robustness concern rather than a security vulnerability.

### [low] internal dependency

Finding ID: `NPS-F2C2A4412BE4`

File: `util/xxhash3/accum_scalar.go`

Imports github.com/bytedance/gopkg/internal/runtimex. The 'internal' path means it can only be imported by code within the bytedance/gopkg module, and it is part of the same package being analyzed, so this is not an external trust boundary crossing.

### [low] unsafe pointer arithmetic

Finding ID: `NPS-B50A23B2AA67`

File: `util/xxhash3/internal/xxh3_raw/xxh3_raw.go`

Extensive use of unsafe.Pointer and pointer arithmetic to read unaligned memory. This is expected for a high-performance hash implementation but requires careful bounds checking to avoid out-of-bounds reads. The code appears to perform correct length-based bounds calculations.

## Files reviewed

- `cache/asynccache/asynccache.go` (medium): No overt malicious patterns (no exfiltration, network calls, shell exec, obfuscation, or credential harvesting) were found, but the code has several concurrency, resource-management, and panic-safety issues that could cause denial of service or crashes in a host application.
- `collection/lscq/asm.go` (medium): No direct malicious patterns (exfiltration, credential theft, backdoors) were found, but the code relies on unsafe pointer manipulation, //go:linkname into runtime internals, and external assembly implementations that require further audit.
- `collection/lscq/asm_arm64.go` (medium): This is a legitimate low-level synchronization primitive from ByteDance's lscq package using unsafe and runtime internals; no malicious patterns such as exfiltration, credential harvesting, or backdoors were found, but the use of unsafe/linkname warrants a warning.
- `collection/skipmap/util.go` (medium): No overt malicious behavior found; the main concerns are the intentional use of `unsafe`/`linkname` to access unexported runtime internals and reliance on an internal hashing dependency whose implementation is not verifiable from this file.
- `collection/skipset/util.go` (medium): The code appears to be a standard skip list utility with a non-idiomatic unsafe linkname to runtime.cmpstring, but no clear malicious patterns were detected.
- `internal/hack/hack.go` (medium): No malicious behavior detected, but the code relies on unsafe pointer manipulation that bypasses Go's memory safety and can cause undefined behavior if misused.
- `internal/runtimex/ppin.go` (medium): The code uses unsafe go:linkname to access Go runtime internals for goroutine pinning; it is a legitimate but fragile technique with no malicious intent detected.
- `internal/runtimex/runtime_go_1.22.go` (medium): The Go file uses unsafe linkname to access an internal runtime function, a risky but common optimization technique without direct malicious indicators.
- `internal/runtimex/runtime_pre_go_1.22.go` (medium): This build-constrained file only exposes a linkname to runtime.fastrand for pre-Go 1.22 compatibility, which is a known-risky but not malicious pattern; no exfiltration, credential harvesting, execution, or network behavior is present.
- `lang/dirtmake/bytes.go` (medium): The code is not overtly malicious but uses unsafe runtime linkname and uninitialized memory allocation, which poses memory-safety and data-leak risks in a third-party package.
- `lang/fastrand/fastrand.go` (medium): The code contains no malicious patterns but uses unsafe pointer casting for performance, which is a potential safety concern.
- `lang/mcache/mcache.go` (medium): Legitimate high-performance memory cache implementation using unsafe pointers and custom allocation, with no malicious patterns detected but potential memory safety concerns.
- `lang/syncx/linkname.go` (medium): No overtly malicious code found, but use of //go:linkname to hook internal sync runtime cleanup functions is a fragile and high-risk pattern that warrants scrutiny.
- `lang/syncx/pool.go` (medium): Legitimate performance-focused sync.Pool reimplementation from ByteDance, but its use of go:linkname runtime internals and unsafe pointer manipulation warrants a warning, though no actual malicious behavior is present.
- `cache/asynccache/atomic_error.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/circuitbreaker/breaker.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/circuitbreaker/circuitbreaker.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/circuitbreaker/counter.go` (safe): No malicious patterns detected; the code implements a standard per-P atomic counter with no network, filesystem, process execution, or obfuscated behavior.
- `cloud/circuitbreaker/interface.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/circuitbreaker/metricer.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/circuitbreaker/panel.go` (safe): No malicious patterns detected; the code implements a circuit breaker panel with standard concurrency controls and no signs of data exfiltration, credential harvesting, obfuscation, or other security concerns.
- `cloud/circuitbreaker/per_p_metricer.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/circuitbreaker/test_helper.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/circuitbreaker/tripfunc.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/metainfo/backward.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/metainfo/http.go` (safe): No malicious patterns detected; the code implements HTTP header to context metainfo conversion with no exfiltration, obfuscation, or process execution.
- `cloud/metainfo/info.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/metainfo/kv.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/metainfo/kvstore.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/metainfo/pool.go` (safe): Cleared by Jev triage; no further analysis needed
- `cloud/metainfo/utils.go` (safe): No malicious patterns detected
- `collection/hashset/hashset.go` (safe): Cleared by Jev triage; no further analysis needed
- `collection/hashset/types.go` (safe): Cleared by Jev triage; no further analysis needed
- `collection/hashset/types_gen.go` (safe): The file is a benign build-time code generator with no malicious patterns, though it performs file I/O and code generation within the package scope.
- `collection/lscq/lscq.go` (safe): No malicious patterns detected; this is a legitimate lock-free concurrent queue implementation using unsafe pointers and atomic operations for performance.
- `collection/lscq/types.go` (safe): No malicious patterns detected in the lscq types.go source file.
- `collection/lscq/types_gen.go` (safe): The file is a Go code generator with build tag 'ignore' that reads a source file and emits a type-specialized version; it contains no network, credential, execution, or other malicious patterns.
- `collection/lscq/util.go` (safe): No malicious patterns detected; the code contains only bitwise utilities and cache-aligned indexing logic for a lock-free queue.
- `collection/skipmap/flag.go` (safe): Cleared by Jev triage; no further analysis needed
- `collection/skipmap/oparray.go` (safe): No malicious patterns detected; the code is a legitimate low-level data structure implementation using atomics and unsafe pointers without any network, filesystem, process, or obfuscation activity.
- `collection/skipmap/skipmap.go` (safe): This is a legitimate concurrent skip-list map implementation from ByteDance with no malicious patterns, network calls, file operations, or credential harvesting.
- `collection/skipmap/types_gen.go` (safe): The code is a benign Go code generation script with no malicious behavior or security concerns.
- `collection/skipset/flag.go` (safe): Cleared by Jev triage; no further analysis needed
- `collection/skipset/oparry.go` (safe): No malicious patterns detected
- `collection/skipset/skipset.go` (safe): No malicious patterns detected
- `collection/skipset/types_gen.go` (safe): No malicious patterns detected; this is a benign Go code generator for skip list types with no network, credential, or system access.
- `collection/zset/oparry.go` (safe): No malicious patterns detected; the code is a legitimate skip list optional array implementation using unsafe.Pointer for performance.
- `collection/zset/opt.go` (safe): Cleared by Jev triage; no further analysis needed
- `collection/zset/skiplist.go` (safe): No malicious patterns detected; the code is a legitimate skip list implementation with no network, filesystem, process spawning, or obfuscated behavior.
- `collection/zset/zset.go` (safe): Cleared by Jev triage; no further analysis needed
- `internal/benchmark/linkedq/linkedq.go` (safe): Cleared by Jev triage; no further analysis needed
- `internal/benchmark/msq/msq.go` (safe): No malicious patterns detected; the code is a standard lock-free queue implementation using unsafe pointers.
- `internal/runtimex/readunaligned.go` (safe): This file only provides low-level unaligned memory read helpers using unsafe pointers with no malicious patterns, network activity, file access, or code execution.
- `internal/runtimex/readunaligned_bigendian.go` (safe): No malicious patterns detected
- `internal/wyhash/digest.go` (safe): No malicious patterns detected; the code is a legitimate implementation of the wyhash algorithm with no exfiltration, credentials harvesting, obfuscation, or other red flags.
- `internal/wyhash/wyhash.go` (safe): No malicious patterns detected; the code implements a standard wyhash hash function using safe unsafe operations without any external communication, credential access, or suspicious behavior.
- `lang/channel/channel.go` (safe): No malicious patterns detected; the code implements a feature-rich channel abstraction with no network, filesystem, process, or credential access.
- `lang/mcache/utils.go` (safe): Cleared by Jev triage; no further analysis needed
- `lang/span/span.go` (safe): Cleared by Jev triage; no further analysis needed
- `lang/stringx/doc.go` (safe): Cleared by Jev triage; no further analysis needed
- `lang/stringx/is.go` (safe): Cleared by Jev triage; no further analysis needed
- `lang/stringx/stringx.go` (safe): No malicious patterns detected; the code contains only standard string manipulation utilities with no network, filesystem, process execution, or obfuscated behavior.
- `lang/syncx/pool_race.go` (safe): Cleared by Jev triage; no further analysis needed
- `lang/syncx/poolqueue.go` (safe): No malicious patterns detected; the code implements a lock-free queue using atomic operations and unsafe pointers for performance without any network, filesystem, process, or credential access.
- `lang/syncx/rwmutex.go` (safe): No malicious patterns detected; the code is a legitimate sharded RWMutex implementation with no security concerns.
- `util/gctuner/finalizer.go` (safe): No malicious patterns detected; the code is a benign Go GC tuning finalizer utility using only runtime and sync/atomic packages.
- `util/gctuner/mem.go` (safe): Cleared by Jev triage; no further analysis needed
- `util/gctuner/tuner.go` (safe): No malicious patterns detected; the code is a legitimate Go GC tuning utility from ByteDance with no exfiltration, credential harvesting, obfuscation, or backdoor behavior.
- `util/gopool/config.go` (safe): Cleared by Jev triage; no further analysis needed
- `util/gopool/gopool.go` (safe): No malicious patterns detected; the code is a standard goroutine pool utility with no network, file, exec, or obfuscated behavior.
- `util/gopool/pool.go` (safe): Cleared by Jev triage; no further analysis needed
- `util/gopool/worker.go` (safe): Cleared by Jev triage; no further analysis needed
- `util/logger/default.go` (safe): Cleared by Jev triage; no further analysis needed
- `util/logger/logger.go` (safe): Cleared by Jev triage; no further analysis needed
- `util/xxhash3/accum.go` (safe): No malicious patterns detected; the file is a simple build-constrained wrapper that delegates to a scalar xxhash3 implementation.
- `util/xxhash3/accum_amd64.go` (safe): No malicious patterns detected; the code is a legitimate optimized hash accumulator dispatch for xxhash3 using unsafe pointers but performs no exfiltration, code execution, or file/network operations.
- `util/xxhash3/accum_scalar.go` (safe): No malicious patterns detected; code is a standard scalar XXH3 hash implementation using unsafe pointer arithmetic for performance, with no network, filesystem, process, or obfuscation activity.
- `util/xxhash3/consts.go` (safe): No malicious patterns detected; the file contains only cryptographic constants and a static secret array used for xxhash3 implementation.
- `util/xxhash3/hash.go` (safe): No malicious patterns detected; the code is a legitimate implementation of the xxHash3 algorithm with only expected low-level unsafe pointer usage for performance.
- `util/xxhash3/hash128.go` (safe): The code is a legitimate implementation of the xxHash3 hashing algorithm with no malicious patterns detected.
- `util/xxhash3/internal/avo/avx.go` (safe): No malicious patterns detected; this is a legitimate AVX2 assembly code generator for xxhash3 hashing functions.
- `util/xxhash3/internal/avo/gen.go` (safe): No malicious patterns detected; the file only contains a build-tagged code generator with flag parsing and internal function calls.
- `util/xxhash3/internal/avo/sse.go` (safe): No malicious patterns detected; this is a legitimate AVO assembly code generator for xxhash3 SSE2 implementation.
- `util/xxhash3/internal/xxh3_raw/xxh3_raw.go` (safe): This is a legitimate XXH3 hash implementation with no malicious patterns; unsafe pointer usage is standard for performance-critical hashing code.
- `util/xxhash3/util.go` (safe): No malicious patterns detected; the file contains only standard xxhash algorithm implementation code using unsafe pointers for performance.

AI analysis is guidance, not a guarantee. Methodology: https://security.togoder.click/methodology