cmd/cgo: fix unaligned arguments typedmemmove crash on iOS

[austinderek]

Irregularly typedmemmove and bulkBarrierPreWrite crashes on unaligned
arguments. By aligning the arguments this is fixed.

Fixes golang#46893

---

🔄 This is a mirror of upstream PR #74868

[staging]

HackerOne Code Security Review

🟢 Scan Complete: 35 Issue(s)
🟠 Validation Complete: One or more Issues looked potentially actionable, so this was escalated to our network of engineers for manual review. Once this is complete you'll see an update posted.

Here's how the code changes were interpreted and info about the tools used for scanning.

ℹ️ Issues Detected

NOTE: These may not require action!

Below are unvalidated results from the Analysis Tools that ran during the latest scan for transparency. We investigate each of these for accuracy and relevance before surfacing them as a potential problem.

How will I know if something is a problem?
When validation completes, any concerns that warrant attention prior to merge will be posted as inline comments. These will show up in 2 ways:

• Expert review (most cases): Issues will be posted by experts who manually reviewed and validated them. These are real HackerOne engineers (not bots) reviewing through an integrated IDE-like tool. You can communicate with them like any other reviewer. They'll stay assigned and get notified with commit & comment updates.
• Automatically: In cases where our validation checks have highest confidence the problem is legitimate and urgent. These will include a description of contextual reasoning why & actionable next steps.

File & Line	Issue
src/encoding/xml/read.go Line 261	The code changes replace type assertions using Interface().(Type) with the new reflect.TypeAssert[Type] function. While this is generally safer, the implementation now checks only if CanInterface() is true before attempting the type assertion, but doesn't verify that the type actually implements the interface before the assertion. The original code explicitly checked both CanInterface() AND Type().Implements(interfaceType) before performing the assertion, which was a more defensive approach. This could potentially lead to runtime panics if a value that doesn't implement the expected interface is processed.
src/cmd/link/dwarf_test.go Line 389	The change adds a check to skip tests on platforms that don't support DWARF symbol tables in executables, and adds a special case for Solaris in the TestFlagW function. This is a test-only change that improves platform compatibility and doesn't introduce security issues.
src/runtime/rt0_netbsd_arm64.s Line 10	The change replaces a BL main(SB) instruction with JMP main(SB). While BL is a branch with link (saves return address), JMP doesn't save the return address. This means the function will not properly return to its caller. In security-sensitive code, this could potentially lead to stack corruption or unexpected behavior if something relies on proper function return.
src/crypto/internal/fips140/entropy/entropy.go Line 128	The entropy source uses a linear congruential generator (LCG) with fixed parameters on lines 128-129 to generate memory access patterns. While this is used only for creating timing variations and not directly for cryptographic purposes, LCGs are predictable and could potentially be exploited to predict the memory access pattern, which might reduce the effectiveness of the entropy collection in certain environments.
src/crypto/internal/fips140/entropy/entropy.go Line 118	The code uses unsafe.Pointer in touchMemory function (line 118) to perform unaligned memory access. While this is intentional for the entropy generation, it could potentially cause memory corruption or undefined behavior on some architectures that don't support unaligned access. The alignment check on line 116 helps mitigate this, but the use of unsafe operations always warrants careful review.
src/runtime/proc.go Line 812	The function getGodebugEarly() has been modified to return a boolean indicating whether the OS provides environment variables early in the initialization sequence. Previously, it would return an empty string if the environment variable wasn't found, which could be ambiguous. Now it returns both the value and a boolean success flag. However, the function also now uses gostringnocopy instead of gostring when extracting the GODEBUG value. This could potentially lead to memory safety issues if the underlying memory for the environment variable is modified while the string is still in use, as gostringnocopy doesn't make a copy of the string data.
src/cmd/link/internal/ld/lib.go Line 1455	The change on line 1455 modifies the condition for adding the -Wl,-S flag to suppress debugging symbols. Previously, this flag was not added for AIX, but now it's also not added for Solaris. This is because the Solaris linker's -S flag has a different meaning than what's intended here. Without this fix, the linker would pass an incorrect flag to the Solaris linker, potentially causing unexpected behavior or errors during linking.
src/crypto/internal/fips140/drbg/rand.go Line 33	The code changes how entropy is obtained for the FIPS 140-3 cryptographic module. The previous implementation used entropy.Depleted to get entropy from an external source, but now it uses a new internal entropy source. If the new entropy source (getEntropy()) is not properly implemented or doesn't meet FIPS requirements, this could compromise the security of all random number generation in FIPS mode. Additionally, the error handling in the new implementation might allow for continued operation after multiple entropy source failures.
src/crypto/internal/fips140/mlkem/mlkem768.go Line 175	The code adds calls to fipsSelfTest() in several functions (generateKey, GenerateKeyInternal768, Encapsulate, EncapsulateInternal, and Decapsulate) but there's no implementation of this function visible in the file. If this function is meant to perform security-critical validation before cryptographic operations, its absence or failure to execute properly could lead to using the ML-KEM implementation without proper validation. This could potentially bypass security checks intended to ensure the implementation meets FIPS requirements.
src/debug/elf/file.go Line 1834	The new putUint function has a potential integer overflow vulnerability. In line 1834, the check math.MaxUint64-start < length is intended to prevent integer overflow when calculating start+length, but it's not sufficient. If start is very large and length is small, the subtraction could overflow, causing the check to fail. A safer approach would be to check if start > math.MaxUint64-length.
src/cmd/cgo/internal/testcshared/cshared_test.go Line 276	The change removes '_cgo_dummy_export' from the Windows DLL export definition file. This symbol was previously exported but is now removed. The code has been refactored to use a new function 'checkNumberOfExportedSymbolsWindows' that properly accounts for this change. The code now correctly handles the case where '_cgo_stub_export' is exported when there are no other symbols exported. This change improves the security posture by reducing the attack surface through fewer exported symbols.
src/cmd/link/internal/ld/pe.go Line 1788	The function peCreateExportFile writes a file to a path specified by *flagTmpdir without proper validation. This could lead to path traversal vulnerabilities if flagTmpdir contains malicious input. The function should validate that the path is safe and within expected boundaries before writing to it. Additionally, the file is created with 0666 permissions, which may be overly permissive depending on the security context.
src/crypto/tls/handshake_server.go Line 360	The change on line 360 modifies an error message to use %q instead of %s when formatting the clientProtos variable. While this is a security improvement, it's a minor one. Using %q ensures that special characters in protocol names are properly escaped in the error message, which prevents potential log injection attacks if these error messages are logged. Without proper quoting, maliciously crafted ALPN protocol names could potentially be used to inject content into logs.
src/crypto/internal/fips140/mlkem/mlkem1024.go Line 116	The code adds calls to fipsSelfTest() in several functions (GenerateKey1024, GenerateKeyInternal1024, Encapsulate, EncapsulateInternal, Decapsulate) but there's no implementation of this function visible in the code. If this function is meant to verify FIPS compliance or perform security checks, but fails silently or doesn't properly validate security properties, it could create a false sense of security while allowing insecure operations to proceed.
src/cmd/link/internal/loader/loader.go Line 1115	The change introduces a new method ForAllCgoExportStatic that returns an iterator over symbols marked with the 'cgo_export_static' compiler directive. This method uses the new Go 'iter' package (imported on line 19) to create an iterator sequence. While the implementation itself is secure, there's a potential issue if the caller doesn't properly handle the iteration. If the underlying map l.attrCgoExportStatic is modified during iteration (by another goroutine), this could lead to undefined behavior or potential crashes. The code should be used in a single-threaded context or with proper synchronization.
src/cmd/link/internal/ld/macho.go Line 109	The changes add two new Mach-O ARM64 relocation types: MACHO_ARM64_RELOC_SUBTRACTOR (line 109) and MACHO_ARM64_RELOC_POINTER_TO_GOT (line 115). These are standard relocation types in the Mach-O format and don't introduce any security vulnerabilities. The changes are simply adding constants to support these relocation types in the Go linker.
src/net/tcpsock_test.go Line 515	The test has been modified to use t.Errorf instead of t.Fatalf in the TestTCPReadWriteAllocs function. While this change itself is not a security vulnerability, it could potentially mask memory allocation issues in the TCP implementation. Memory allocations in network code can sometimes lead to performance degradation under load or even resource exhaustion attacks. However, since this is just a test file and the change only affects how test failures are reported (error vs fatal), the security impact is minimal.
src/internal/poll/fd_windows.go Line 241	The code introduces runtime.Pinner to pin memory during I/O operations, but there's a potential race condition in the pin/unpin mechanism. The pin() method pins memory for read/write operations, but if an error occurs between pin() and execIO(), the memory might be unpinned too early or not at all. While execIO() has a deferred unpin, there are code paths where pin() is called but execIO() might not be called, potentially leading to memory leaks or use-after-free scenarios.
src/cmd/compile/internal/ssa/rewrite.go Line 2750	The added function isDictArgSym checks if a symbol is a dictionary argument by comparing its name to a constant LocalDictName. While this is not a vulnerability itself, it's worth noting that the function doesn't perform any null checks before dereferencing the symbol as an *ir.Name. If sym is nil or not of type *ir.Name, this would cause a panic. This is a defensive programming issue rather than a security vulnerability.
src/encoding/xml/marshal.go Line 448	The code changes replace the use of type assertions via Type.Implements() with the new reflect.TypeAssert function. While this is generally a good change, there's a potential issue with the error handling. The original code checked if a type implements an interface before attempting to use it, but the new code uses reflect.TypeAssert which returns a boolean indicating success. If the type assertion fails, the code continues execution rather than returning an error. This could lead to unexpected behavior if the code assumes the assertion succeeded when it actually failed.
src/cmd/cgo/out.go Line 1061	The code adds a maxAlign variable to track the maximum alignment among all fields in a struct, and then uses this value to explicitly align the struct with __attribute__((aligned(maxAlign))). This fixes a potential security issue where improper alignment could lead to memory access violations or undefined behavior when passing data between Go and C. Without proper alignment, the struct could be accessed in ways that trigger undefined behavior, especially on architectures with strict alignment requirements.
src/internal/buildcfg/cfg.go Line 450	The code changes remove conditional checks for WASM features (SatConv and SignExt) and make them always enabled. While this change itself doesn't introduce security vulnerabilities, it modifies the behavior of the gogoarchTags() function to always include these features in the tags list regardless of the actual GOWASM configuration. This could potentially lead to unexpected behavior if any security-sensitive code relies on these tags for feature detection or conditional compilation. The change should be carefully reviewed to ensure it doesn't break any security assumptions in dependent code.
src/cmd/link/internal/ld/symtab.go Line 657	The change on line 657 replaces a custom slice creation with sliceSym(pcln.pclntab). The original code was using slice(pcln.pclntab, uint64(ldr.SymSize(pcln.pclntab))) which is functionally equivalent to sliceSym but inconsistent with the pattern used elsewhere. While not a direct security issue, inconsistent memory handling patterns can lead to maintenance errors that introduce vulnerabilities.
src/cmd/link/internal/ld/symtab.go Line 648	The change on line 648 replaces sliceSym(pcln.cutab) with slice(pcln.cutab, uint64(ldr.SymSize(pcln.cutab))/4). This divides the size by 4, which suggests the original code was incorrectly calculating the slice length. The cutab likely contains 4-byte elements, but the original code was treating the byte size as the element count. This could lead to accessing memory beyond the intended bounds, potentially causing crashes or memory corruption in the runtime.
src/runtime/runtime1.go Line 405	The code refactoring splits the debug variable parsing into multiple functions, but introduces a potential issue where parseRuntimeDebugVars no longer initializes the godebugEnv variable immediately. This could lead to a race condition where other parts of the runtime might access the uninitialized godebugEnv variable between the calls to parseRuntimeDebugVars and finishDebugVarsSetup. If any code depends on godebugEnv being initialized immediately after parsing debug variables, it could lead to unexpected behavior.

🧰 Analysis tools

• [ ✅ ] HackerOne AI Code Analysis
• [ ✅ ] HackerOne AI Code Validation
• [ ✅ ] semgrep
• [ ✅ ] gosec
• [ ✅ ] bandit

⏱️ Latest scan covered changes up to commit 46ae8b9 (latest)